Parcel data acquisition and processing

ABSTRACT

In some embodiments, scripts may be used to perform parcel data acquisition, conversion, and clean-up/repair in an automated manner and/or through graphical user interfaces. The scripts may be used, for example, to repair geometries of new parcel data, convert multi-part parcel geometries to single part parcel geometries (explode), eliminate duplicate parcel geometries, append columns, create feature classes, and append feature classes. These scripts may be executed in a predetermined manner to increase efficiency. In some embodiments, different combinations of attributes may be appended to stored parcel data. In some embodiments, a tracking application may be used to track information about sources of data. In some embodiments, a tracking application may be used to track which system users are assigned to specific tasks (e.g., in a data acquisition project).

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a Continuation application and is based upon andclaims the benefit of priority under 35 U.S.C. §120 for U.S. Ser. No.13/012,310, filed Jan. 24, 2011, which is a Continuation of U.S. Ser.No. 11/999,319 filed Dec. 4, 2007, the entire contents of each which areincorporated herein by reference.

PRIORITY CLAIMS

This application claims benefit of priority of U.S. Provisional PatentApplication Ser. No. 60/872,831 titled “PARCEL DATA ACQUISITION ANDPROCESSING”, filed on Dec. 5, 2006, which is hereby incorporated byreference in its entirety as though fully and completely set forthherein.

BACKGROUND

1. Field of the Invention

The present invention relates generally to data and, more specifically,to parcel data processing and acquisition.

2. Description of the Related Art

Several market sectors may have an interest in data for specificparcels. Entities such as banks, insurance companies, real estateagents, government agencies, and utility 20 providers may need parcelspecific data. For example, real estate agents may need a parcelvaluation to use in considering an offer for a specific parcel. Asanother example, a bank may need to know whether a parcel they areproviding a mortgage for is in a high-risk flood zone. Because of thewide range of sources of information for parcels, it may be difficultfor companies to locate information for a particular property withoutconsulting several sources of data.

SUMMARY

In some embodiments, scripts may be used to perform data standardizationand/or normalization of parcel data from different sources into a commonformat database or collection of databases. For example, data may becollected from sources (e.g., external) and scripts may be used toconvert the data, clean-up/repair data, and track data during theacquisition process. Scripts may perform these functions in an automatedmanner or may execute with manual assistance from a system user (e.g.,through a graphical user interface). The scripts may be used, forexample, to repair geometries of new data, convert multi-part parcelgeometries to single part parcel geometries (explode), eliminateduplicate parcel geometries, append columns, calculate attribute values,create feature classes, and append feature classes. These scripts mayalso be executed in a predetermined manner to increase efficiency. Forexample, the explode script may be executed before the eliminateduplicate geometries script to avoid duplicate geometries that may becreated as a result of the explode script. The scripts may be designedfor and may be dependent on the source of the parcel data. These scriptsmay be written in a scripting language and executed in an EnvironmentalSystems Research Institute's (ESRI's) modeling environment. Otherenvironments are also contemplated.

In some embodiments, multiple scripts may be performed at approximatelythe same time. For example, a system executing the scripts maymulti-thread the scripts. In some embodiments, the scripts may berecursive scripts. In some embodiments, as the scripts execute, a logfile may be generated with information about the execution of thescripts (including exceptions, errors, values outside establishedparameters, etc.).

In some embodiments, different combinations of attributes may beappended to acquired parcel data. For example, the Assessor's ParcelNumber (APN), Tax identification (ID) number, and situs information(such as mailing address, state, zip code, owner's name, flood zone,elevation of insurable property, etc.) may be stored for associatedparcel data (e.g., for an associated parcel description). Attributes mayalso provide links to other data. For example, while an APN may bestored with a parcel description, it may also provide a link toadditional data about the parcel in a different database.

In some embodiments, a tracking application may be used to track sourcesof data for the common format database including data that is alreadyin-house, data that can be acquired from a source at low cost, data thatcan be acquired from a source at high cost, and data that is notavailable. The tracking application may be used to keep track of thechanging status of the data sources (e.g., data sources may become newlyavailable or more expensive). The tracking application may also trackthe type and state of the data available and/or being added to thecommon format database (e.g., whether the data from a particular sourcewill require a lot of work to repair, etc.). The tracking applicationmay also track potential sources of attribute data (e.g., for attributesnot stored in the system).

In some embodiments, a tracking application may be used to trackinformation about parcel projects. For example, the tracking applicationmay track which system users are assigned to specific tasks. In someembodiments, the tracking application may be used to assign dataacquisition/preparation tasks, etc. The tracking application may also beused to view the current assignments, to change/edit assignments, etc.

In some embodiments, tracking application data may be stored as one ormore relationships assigned to parcel data. For example, a relationshipmay indicate a contact source for the data and another relationshipassociated with the parcel data may indicate the identity of a systemuser assigned to process the parcel data.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention may be obtained when thefollowing detailed description is considered in conjunction with thefollowing drawings, in which:

FIG. 1 illustrates an embodiment of a wide area network (WAN) and alocal area network (LAN).

FIGS. 2 a-b illustrate an embodiment of computer system that may besuitable for implementing various embodiments of a system and method forparcel data acquisition and tracking.

FIG. 3 illustrates geometric elements for geometry repair, according toan embodiment.

FIGS. 4 a-b illustrate parcel maps, according to an embodiment.

FIG. 5 illustrates a personal geodatabase, according to an embodiment.

FIG. 6 a illustrates a flowchart for executing scripts to createpersonal geodatabases (PGDBs), according to an embodiment.

FIG. 6 b illustrates a flowchart of a script order, according to anembodiment.

FIGS. 7 a-b illustrate parcel data and updated parcel data, according toan embodiment.

FIG. 8 illustrates a flowchart for a method of tracking the status ofthe data sources, according to an embodiment.

FIG. 9 a illustrates a panel for creating a project to be assigned,according to an embodiment.

FIG. 9 b illustrates a panel for adding tasks to the project, accordingto an embodiment.

FIG. 9 c illustrates a panel for viewing tasks of the project, accordingto an embodiment.

FIG. 10 illustrates a resulting panel listing tasks of the project,according to an embodiment.

FIGS. 11 and 12 illustrate panels for editing details for a task,according to an embodiment.

FIG. 13 illustrates a panel for adding a resource, according to anembodiment.

FIGS. 14-15 illustrate panels for editing the resource, according to anembodiment.

FIGS. 16 a-b illustrate panels for county resource relationships,according to an embodiment.

FIGS. 17-18 illustrate panels for adding a county relationship,according to an embodiment.

FIG. 19 illustrates a panel for listing a county resource relationship,according to an embodiment.

FIGS. 20 a-b illustrate panels for parcel inventory searches, accordingto an embodiment.

FIG. 21 illustrates a panel for parcel inventory search results,according to an embodiment.

FIG. 22 illustrates a panel of parcel resource detail, according to anembodiment.

FIG. 23 illustrates a resource inventory search panel, according to anembodiment.

FIG. 24 illustrates a second resource inventory results panel, accordingto an embodiment.

FIGS. 25 a-b illustrate a workflow interface for management of parceldata, according to an embodiment.

FIG. 26 illustrates a resource summary interface, according to anembodiment.

FIG. 27 illustrates a resource relationship summary for a county,according to an embodiment.

FIG. 28 illustrates an edit relationship summary interface for aresource, according to an embodiment.

FIG. 29 illustrates a resource relationship summary for an individual,according to an embodiment.

FIG. 30 illustrates a resource inventory search interface, according toan embodiment.

FIG. 31 illustrates a flowchart for purchasing and incorporating data,according to an embodiment.

FIGS. 32 a-d illustrate a flowchart for assessing a legal status ofacquired data, according to an embodiment.

FIG. 33 illustrates a flowchart for data acquisition, according to anembodiment.

FIG. 34 illustrates the table structures for databaseprocessing/acquisition, according to an embodiment.

FIG. 35 illustrates a flowchart for database acquisition, according toan embodiment.

While the invention is susceptible to various modifications andalternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Itshould be understood, however, that the drawings and detaileddescription thereto are not intended to limit the invention to theparticular form disclosed, but on the contrary, the intention is tocover all modifications, equivalents, and alternatives falling withinthe spirit and scope of the present invention as defined by the appendedclaims. Note, the headings are for organizational purposes only and arenot meant to be used to limit or interpret the description or claims.Furthermore, note that the word “may” is used throughout thisapplication in a permissive sense (i.e., having the potential to, beingable to), not a mandatory sense (i.e., must). The term “include”, andderivations thereof, mean “including, but not limited to”. The term“coupled” means “directly or indirectly connected”.

DETAILED DESCRIPTION OF THE EMBODIMENTS

FIG. 1 illustrates an embodiment of a WAN 102 and a LAN 104. WAN 102 maybe a network that spans a relatively large geographical area. TheInternet is an example of a WAN 102. WAN 102 typically includes aplurality of computer systems that may be interconnected through one ormore networks. Although one particular configuration is shown in FIG. 1,WAN 102 may include a variety of heterogeneous computer systems andnetworks that may be interconnected in a variety of ways and that mayrun a variety of software applications.

One or more LANs 104 may be coupled to WAN 102. LAN 104 may be a networkthat spans a relatively small area. Typically, LAN 104 may be confinedto a single building or group of buildings. Each node (i.e., individualcomputer system or device) on LAN 104 may have its own CentralProcessing Unit (CPU) with which it may execute programs. Each node mayalso be able to access data and devices anywhere on LAN 104. LAN 104,thus, may allow many system users to share devices (e.g., printers) anddata stored on file servers. LAN 104 may be characterized by a varietyof types of topology (i.e., the geometric arrangement of devices on thenetwork), of protocols (i.e., the rules and encoding specifications forsending data, and whether the network uses a peer-to-peer orclient/server architecture), and of media (e.g., twisted-pair wire,coaxial cables, fiber optic cables, and/or radio waves).

Each LAN 104 may include a plurality of interconnected computer systemsand optionally one or more other devices. For example, LAN 104 mayinclude one or more workstations 110 a, one or more personal computers112 a, one or more laptop or notebook computer systems 114, one or moreserver computer systems 116, and one or more network printers 118. Asillustrated in FIG. 1, an example LAN 104 may include one of eachcomputer systems 110 a, 112 a, 114, and 116, and one printer 118. LAN104 may be coupled to other computer systems and/or other devices and/orother LANs through WAN 102.

One or more mainframe computer systems 120 may be coupled to WAN 102. Asshown, mainframe 120 may be coupled to a storage device or file server124 and mainframe terminals 122 a, 122 b, and 122 c. Mainframe terminals122 a, 122 b, and 122 c may access data (e.g., a database 125) stored inthe storage device or file server 124 coupled to or included inmainframe computer system 120. In some embodiments, the database 125 maybe stored in other mediums.

WAN 102 may also include computer systems connected to WAN 102individually and not through LAN 104. For example, workstation 110 b andpersonal computer 112 b may be connected to WAN 102. For example, WAN102 may include computer systems that may be geographically remote andconnected to each other through the Internet.

FIGS. 2 a-b illustrates an embodiment of computer system 250 that may besuitable for implementing various embodiments of a system and method forparcel data acquisition and tracking. Each computer system 250 typicallyincludes components such as CPU 252 with an associated memory mediumsuch as Compact Disc Read-Only Memories (CD-ROMs) 260. The memory mediummay store program instructions for computer programs. The programinstructions may be executable by CPU 252. Computer system 250 mayfurther include a display device such as monitor 254, an alphanumericinput device such as keyboard 256, and a directional input device suchas mouse 258. Computer system 250 may be operable to execute thecomputer programs to implement computer-implemented systems and methodsfor parcel data acquisition and tracking.

Computer system 250 may include a memory medium on which computerprograms according to various embodiments may be stored. The term“memory medium” is intended to include an installation medium, e.g.,floppy disks or CD-ROMs 260, a computer system memory such as DynamicRandom Access Memory (DRAM), Static Random Access Memory (SRAM),Extended Data Out Random Access Memory (EDO RAM), Rambus Random AccessMemory (RAM), etc., or a non-volatile memory such as a magnetic media,e.g., a hard drive or optical storage. The memory medium may alsoinclude other types of memory or combinations thereof. In addition, thememory medium may be located in a first computer, which executes theprograms or may be located in a second different computer, whichconnects to the first computer over a network. In the latter instance,the second computer may provide the program instructions to the firstcomputer for execution. Computer system 250 may take various forms suchas a personal computer system, mainframe computer system, workstation,network appliance, Internet appliance, personal digital assistant (PDA),television system or other device. In general, the term “computersystem” may refer to any device having a processor that executesinstructions from a memory medium.

The memory medium may store a software program or programs operable toimplement a method for parcel data acquisition and tracking. Thesoftware program(s) may be implemented in various ways, including, butnot limited to, procedure-based techniques, component-based techniques,and/or object-oriented techniques, among others. For example, thesoftware programs may be implemented using ActiveX controls, C++objects, JavaBeans, Microsoft Foundation Classes (MFC), browser-basedapplications (e.g., Java applets), traditional programs, or othertechnologies or methodologies, as desired. A CPU such as host CPU 252executing code and data from the memory medium may include a means forcreating and executing the software program or programs according to theembodiments described herein.

Various embodiments may also include receiving or storing instructionsand/or data implemented in accordance with the foregoing descriptionupon a carrier medium. Suitable carrier media may include storage mediaor memory media such as magnetic or optical media, e.g., disk or CD-ROM,as well as signals such as electrical, electromagnetic, or digitalsignals, may be conveyed via a communication medium such as a networkand/or a wireless link.

In some embodiments, data (e.g., parcel data 300) for differentgeographical areas may be combined into a common format database 125 (orcollection of databases) using a common formal. In some embodiments,parcel data 300 stored in the common format database 125 may be storedas a parcel layer that includes parcel descriptions (e.g., boundarycoordinates) and linked attribute data for several parcels. In someembodiments, parcel data 300 for different regions in the United Statesmay be combined into a national digital parcel layer. Other countriesare also contemplated. In addition, different parcel layer sizes arealso possible. For example, the regions of a state may be collected intoa statewide parcel layer. The parcel layer may encompass data for theentire region or may be incomplete. For example, some of the regions inthe parcel layer may not have parcel data 300 or may not provide theirparcel data 300 for general use. The combined data in the common formatdatabase 125 may be accessed by different entities for differentreasons. For example, a bank may access the combined data to determine aflood zone type for a parcel of land (e.g., to determine whether toextend a loan for its purchase). Other access reasons are alsocontemplated. For example, the parcel data may be accessed for locationbased services (e.g., navigation systems, online mapping, telematics,cell phone services), flood risk assessment tasks, etc.

In some embodiments, parcel data 300 may be collected from varioussources to place into the common format database 125. In someembodiments, acquired data may be formatted into spatial parcel datafiles to be automatically loaded into a spatially enabled databasethrough a spatial database interface (SDI) 511. Scripts may assist inthe formatting and loading of the data. In some embodiments, the dataoriginating from these various sources may be collected and formattedfor placing in the common format database 125. For example, the commonformat database 125 may be a spatially enabled database accessed throughan SDI 511 (see FIG. 5). In some embodiments, the common format database125 may be a Spatial Database Engine (SDE) (e.g., hosted on a MicrosoftSQL Server™ (Structured Query Language Server)) or an Oracle™ database(which may have a spatial database option). Other database types andother server types are also contemplated. Various entities, includingindividual communities and companies, may also be sources of data onvarious regions. In addition, different types of data may be collectedfrom different sources. For example, data from one source may includescanned paper maps while data from another source may include lists ofcurrent parcel owners. The different types of data may be acquired intoa common format database 125 for later retrieval. In addition, becausethe data is stored together, it may be easier to retrieve differenttypes of data (e.g., to analyze a particular parcel) for parcels indifferent regions. Data may be stored in a database 125 managed by adatabase application. Applications accessing the data in the database125 may interface with the database application managing the database125. In some embodiments, data may be stored in a database 125 and thedatabase 125 may be accessed directly by applications accessing the data(e.g., the application accessing the data may include programminginstructions allowing the application to directly access the database125 without requiring an intermediary database application). Otherdatabase and database access is also contemplated. In some embodiments,SDE data may include a separate layer of indices built on top of thedata in the SDE database (which may require a separate application tointerface with the SDE database) while in an Oracle™ database, theindices may be built into the database (allowing more types ofapplications to directly access the Oracle™ database without anintermediary database application). Other database configurations arealso contemplated. While many different formats may be used, includingthose described herein, it is to be understood that other formats forthe common format database 125 are also contemplated. Placing parceldata from several different sources into a common format for the commonformat database 125 may allow easier access of the data (e.g., by systemusers and/or applications). The parcel data in the common formatdatabase may be used for location based services (e.g., navigationsystems, online mapping, telematics, cell phone services), flood riskassessment tasks, etc. Other uses for the parcel data are alsocontemplated.

In some embodiments, scripts may be used to acquire data from differentsources and used to put the data into a common format for storage in thecommon format database 125. For example, scripts may be used to performparcel data acquisition, conversion, and clean-up/repair. Scripts mayallow data processing in an automated manner or may assist a system userin manual processing (e.g., through a graphical user interface). Agraphical user interface may also be used to set-up and assist scriptsin automated processing. In some embodiments, scripts may be preparedand executed in an ESRI modeling environment. In some embodiments,scripts may use predefined ESRI functions and/or new functions. Scriptsmay be written in, for example, Visual Basic (V-Basic) or Python. Otherprogramming languages and environments are also contemplated. Thescripts may be designed for and may be dependent on a source of theparcel data 300 (e.g., different sources of data may have differentqualities of data). As the scripts execute, a log file 701 may begenerated with information about the execution of the scripts (includingexceptions, errors, values outside established parameters, etc.).

In some embodiment, scripts may be used, for example, to convert parceldata 300 from shape-files 703 (see FIG. 7) into a common format forstorage in a common format database 125. Shape-files 703 may includefiles received from outside sources. Shape-files 703 may include variouslevels of data. For example, some shape-files 703 may only includeparcel geometry (e.g., data points, such as parcel descriptioncoordinates, for a polygon defining parcels) while other shape-files 703may provide parcel geometry and several related attributes. Coordinatesmay include latitude/longitude coordinates or other coordinate types.Shape-files 703 may also include designators to indicate wherecoordinates begin and end for a geometry (e.g., the coordinates for ageometry may be placed on the same line or may be surrounded on eitherside by a geometry indicator (such as an asterisk or backslash). Othershape-file formats are also contemplated. Part of the conversion mayinclude converting parcel data 300 from raster format to vector format(e.g., by digitizing the raster image). Raster formats may include, forexample, Joint Photographic Experts Group (JPEG) and Graphic InterchangeFormat (GIF) files. Other raster formats are also contemplated. Thescripts may also convert other digital data formats into a standardizeddata format. The scripts may also be used to georeference parcel datamaps 400. For example, a parcel data map 400 may be placed over ageographic coordinate map (e.g., physically or digitally) and the parceldata map 400 may be moved and/or resized (e.g., through script executionand/or system user interaction) to fit the parcels (e.g., parcel 401) onthe parcel data map 400 with their correct coordinates. In someembodiments, coordinates may be assigned to relevant portions of theoverlaid parcel data map 400.

As seen in FIG. 3, in some embodiments, scripts may be used toclean-up/repair geometries of received (i.e., original) parcel data 300(which may include latitude/longitude coordinate data points for aparcel geometry (or another format for the geometry coordinates)) forstorage of the data in the common format database 125 (other parcel data300 and parcel data formats are also contemplated). For example, parceldata 300 a,b with incorrect geometries (such as one and/or two pointpolygons) may be repaired. The one-point polygon 301 and two-pointpolygon 305 may be correctly joined with other points to form a polygonor may be eliminated. Polygon 307 with a dangle 309 may also becorrected (e.g., to remove the dangle 309). In some embodiments,correction may include removing the coordinates for the extra dangle 309from the parcel data 300 c (e.g., the script may analyze the parcel data300 to determine which coordinates define an enclosed polygon and whichcoordinates are extra). Other corrections are also contemplated.

In some embodiments, the scripts may be used to convert multi-partparcel geometries of the original data to single part parcel geometries(explode). In some embodiments, a multi-part parcel feature may includetwo or more polygons with similar or equal attributes combined togetherin a single geometry describing the parcel (e.g., two sets ofcoordinates defining polygon 307 may be included where only one set isneeded). Exploding these multi-part features may result in independententries for the polygons previously combined in the multi-part parcelfeature (exploding may include analyzing the polygons for overlap and/orduplication). Eliminating these multi-part features may decrease parcelfeature complexity and may facilitate geometry comparison amongpolygons. For example, the excess polygons may be eliminated leaving onepolygon for the parcel feature.

In some embodiments, the scripts may be used to eliminate duplicateparcel geometries of the original data. In some data sets, a parcel mayhave at least two polygons (a first polygon and at least one duplicateof the first polygon) associated with the same attributes. For example,time-share property descriptions may have multiple owners for the sameparcel of land. Although the APN and the parcel boundaries for theparcel of land of the time-share may be the same, the original data mayhave duplicate polygons for the owners. Upon review, if these duplicatepolygons are not necessary (e.g., contain attributes not needed in thedatabase 125), a script may be used to compare the geometries and findand eliminate the extra polygons. The script may use one or more logicaltests (e.g., in a series) to determine which one of the polygons shouldbe kept and which should be eliminated (because they are duplicates).

In some embodiments, as seen in FIG. 5, a common format may includeusing PGDBs 501 in the database 125 (e.g., created and/or accessedthrough SDI 511) that stores geographic information using standardrelational database architecture. Other formats are also contemplated.The PGDB 501 may include both a feature class 503 and tabular data 509(e.g., tabular attributes, columns, etc.) linked to the feature class503. The feature class 503 may include a description of a geographicobject (e.g., a polygon or street). The feature class 503 may includeseveral fields 507 (including an object identifier, shape coordinates(e.g., a table of rows indicating the coordinates of the shape), a shapearea, and a shape length). Other fields 507 may also be stored with thefeature class 503. Feature classes 503 may also be used to storecenterline coordinates for streets (which may not have a correspondingshape area). In addition to feature classes 503, the PGDB 501 may storerelated attributes in tabular form (e.g., tabular data 509).

In some embodiments, the scripts may be used to integrate parcelgeometries. In some embodiments, integration may be performed afterindividual feature geometries of the polygons have been repaired. AnIntegrate script (e.g., integrate parcel geometries script) used in ESRImay analyze the relationship of the features in a feature class 503(e.g., for a parcel geometry). For example, the script may examine thelocation of the nodes of a polygon in relation to other nodes of otherpolygons in the same feature class. If two nodes are determined to bewithin a predefined threshold (cluster tolerance) then one of the nodesmay be eliminated. For example, if two adjacent polygons both have aboundary (as defined by one or more nodes) and the distance betweenthese boundaries is less than the cluster tolerance, then the twoboundaries may become coincident through the integration script. Theintegration procedure may be used to clean-up data and remove nodes thatmay not be needed. Also, small gaps and slivers in the geometry betweenpolygons may be eliminated to improve the aesthetics of the parcelfeatures (e.g., as shown on a resulting parcel map 400).

In some embodiments, the scripts may be used to append columns. Anappend columns script may be used to create columns (for the parcel data300) that have the same name as a corresponding column in an SDI featureclass. These columns may then be used to temporarily store the relevantdata to be transferred to the database 125. Another reason to create(i.e., append) columns is to hold intermediate data used in somescripts. For example the DUPES and DUPENUM fields may be used in thescript that eliminates duplicate data.

In some embodiments, the scripts may be used to create feature classesand/or append feature classes. In some embodiments, the scripts may usedata that was originally stored in shape-files 703. Because PGDB sizelimitations may be limited, (for example, less than two Gigabytes insome embodiments) separate PGDBs may be created during the processing.For example, the script may eliminate multi-part features from theoriginal parcel data 300 and output the resulting feature class to atemporary PGDB. By creating a temporary PGDB, the original data may beusable, as it was acquired, for other processing. In addition, furtherprocessing may be performed on the temporary PGDB. In some embodiments,another PGDB may be created to contain the final output. The final PGDBmay include a feature class that emulates the structure and settingsthat define the master parcels table (feature class) (which may be anationwide table in some embodiments) that is stored on a database 125(e.g., a LAN database) and accessed by SDI 511 (referred to herein asthe “SDI clone”). Inside the final PGDB the SDI clone may be created byaccessing the master database table through SDI 511 and creating astandalone feature class using the master database table as a template.The features generated by using the script to process the temporary PGDBfeature class may be appended to this SDI clone feature class in thefinal PGDB. This may facilitate loading the SDI clone features andattributes to the master database table using the SDI interface.

FIGS. 4 a-b illustrates a parcel map 400 creatable with parcel data 300,according to an embodiment. In some embodiments, the resourcesidentified and detailed in FIGS. 13-24 may provide data describingparcels (e.g., parcel 401) from parcel maps (e.g., parcel map 400). Theparcel map 400 may be in raster form or vector form. Other forms arealso possible. For example, other digital formats of data may bereceived and converted into a standard format for the common formatdatabase 125. As another example, the data may include a parcel map 400which may be a paper map. The paper map may be scanned into the systemfor conversion and placed into a common format database 125.

As seen in FIG. 5, in some embodiments, geographic data may be stored inPGDBs 501. Multiuser geodatabases may also be used. The common formatPGDBs 501 may be accessed/modified by an SDI interpreter. The PGDB 501may be stored using Structured Query Language (SQL). Other languages andinterpreters may also be used.

FIG. 6 a illustrates a flowchart for processing acquired parcel data 300to place into a common format database 125, according to an embodiment.It should be noted that in various embodiments of the methods describedbelow, one or more of the elements described may be performedconcurrently, in a different order than shown, or may be omittedentirely. Other additional elements may also be performed as desired.Parts or all of the process shown in the flowchart of FIG. 6 a may beautomated (e.g., performed by a computer system).

At 601, parcel data 300 may be acquired. Parcel data 300 may be acquiredfrom several different sources including communities (e.g., from aGeographic Information System (GIS) department, recorder's office, ortax assessor's office) and private corporations.

At 603, the parcel data 300 may be reviewed. The parcel data 300 may bereviewed by a computer system or by a system user (e.g., visually). Insome embodiments, the data may be projected (e.g., over a coordinatemap), to align and determine the data's correct coordinates. Points onthe parcel data 300 may then be associated with the determinedcoordinates. The data may also be reviewed for spatial accuracy.Attribute data associated with the parcel data 300 may also be reviewed.

In some embodiments, determining spatial accuracy and projecting theparcel data 300 may include visual and/or automated review. In someembodiments, visual review (or automated review) of data may includeprojection of the data to confirm projection exists and that the data isaligned with projected data in the SDI 511. Confirming the projectionexists may include examining metadata of a shape-file 703 or PGDB 501 ofthe original data. If there is no projection, the data may be projected(e.g., using a project tool from ArcCatalog™) according to coordinates(e.g., projected onto state plane coordinates appropriate for the data'sstate and location in the state). If a projection is not applicable froma state plane, a custom projection may be used. For example, acounty/city/township may be contacted to acquire projection informationor actual projection files (which may have a .prj extension) to use inthe projection. In some embodiments, data lines (such as parcelboundaries and street centerline data (e.g., by a third party such asGlobal Descriptor Table (GDT) Teleatlas) (other sources of streetcenterline data are also contemplated) may be checked to determinewhether they line up with SDI 511. For example, parcels boundaries oneach side of a street may be an equal distance from the streetcenterlines that may trace the middle of the street. The data may bechecked after the data has been projected or the file has been receivedwith proper projection metadata or a .prj file associated with theshape-files 703 or PGDB. In some embodiments, spatial accuracy may bechecked by visually comparing a border of a map (e.g., a state map) withthe border of the parcel data 300 to determine if the parcel data 300matches existing data (e.g., by comparing street centerline data andDigital Orthophoto Quarter-Quadrangle (DOQQ) aerials). In someembodiments, attribute characteristics may be verified. For example, theAPN, address, and owner names stored with the data may be checked forusability (e.g., to make sure they exist and are in an appropriateformat). Other methods for reviewing the data may also be used.

In some embodiments, at 605, a determination may be made whether thereceived parcel data 300 is in the form of a shape-file 703 (e.g., in an.shp format).

At 607, if the received data is in the form of a shape-file 703, ascript may be used to convert the shape-file feature class into a PGDBfeature class.

At 609, attributes of the parcel data 300 may be manipulated. Forexample, attribute values associated with the parcel data 300 may beformatted and/or concatenated to be loaded. For example, the attributesmay be formatted using Microsoft Access™ database software if thefeature class is contained in a PGDB. In some embodiments, a shape-filefeature class may be converted to a PGDB feature class to facilitate useof Microsoft Access™ database software (or a different format tofacilitate use of a different database software). In some embodiments,attribute manipulation may include manipulating data by creatingadditional fields, if needed, for data from separate databases (e.g.,from other sources), concatenating data that is separated into manyfields, cleaning data with database queries (e.g., eliminating extra0's, spaces, etc.), and confirming address attributes using streetfeature class (e.g., including street centerline data) as well as usinga database's address values for corresponding locations. For example,street names (e.g., included in the street centerline data) may becompared to addresses in the parcel data 300.

At 611, the parcel data 300 may be formatted to append into the commonformat database 125 (e.g., the parcel data 300 may be arranged into thesame format (e.g., to match formats used for the other feature classes,rows, columns, etc.) used in the common format database 125). Forexample, as described herein, parcel data 300 from shape files 703 maybe converted from raster format to vector format (if vector format isthe common format used in the common format database 125) andvice-versa. Other formats may also be used. In some embodiments, spatialindices may be created (e.g., manually by a system user or automaticallyby a computer system) for the parcel data 300 (e.g., through scripts)(which may also have been converted, for example, from raster format tovector format for the database 125) that may then be used to append theparcel data 300 into existing spatial data files (e.g., using thescripts described herein).

In some embodiments, the new parcel data may be compared to data alreadyin the common format database 125. An analyzing script may determinewhich data is different and may determine a footprint (e.g., withlocation information) for the new data. The data in thespatially-enabled database 125 may be updated/replaced with respectivenew data according to the footprint. The data may also beupdated/replaced without developing a footprint. In some embodiments,the script may selectively analyze and update the common format database125 with data as needed. In some embodiments, updates may be divided anda portion of the update may be applied to the database 125. For example,if subscribing to a county database, an update from the county may bedivided (e.g., to include/remove specified parts of the data) and aportion of the county update may be applied to the database 125.

In some embodiments, the SDI 511 may be used to create the spatialindices (e.g., manually by a system user or automatically, for example,by an application that analyzes the data to determine the correspondingspatial indices) for the data in the file. The indices may indicatewhich rows in the spatially enabled database 125 should be appended withthe data from the file. For example, an “append” function may be used toput the new data in the spatially enabled database 125 (e.g., using theindices).

In some embodiments, a script may create a PGDB 501 with a feature class503 (within a feature dataset 505), using SDI 511 and existing parceldata as a template, to load into a common format database 125. Forexample, a new PGDB 501 may be created with new data (e.g., the scriptmay use new parcel data 300, received from a resource, in the featureclass 503) or an existing PGDB 501 may be updated by creating a new PGDB501 with updated feature class information. The new PGDB 501 may bemodeled after the PGDB 501 it will replace (e.g., with similar fields507, etc.). The script may then process the acquired parcel data 300. Invarious embodiments, processing data for appending into the commonformat database 125 may include preparing the data for placing intoPGDBs 501. For example, processing may include exploding (breakingapart) multi-part features (e.g., a shape with multiple parcels) andeliminating duplicate polygons of parcels in the PGDBs 501. Processingmay also include other methods of preparing the data.

In some embodiments, processing may include creating and calculatingfields 507 to contain relevant/available data for the feature class 503and appending the features with the new populated fields 507 into an SDIclone (e.g., a feature class emulating a master database table structurestored on a database 125 (e.g., a LAN database) and accessed by SDI511). In some embodiments, processing may also include repairinggeometry, integrating the geometry, and eliminating duplicate polygons.Field entries for the PGDBs 501 may remain empty if there is no realdata to place in the field 507. The resulting SDI clone feature class503 may have field names that match master database table columnstructures and fields populated with relevant/available data. In someembodiments, the SDI clone may be created, and the feature integrity maybe insured. Trim fields may be loaded, and the features may be appendedto PGDB. The SDI clone feature class may also be created.

In some embodiments, inputs to the scripts (e.g., for formatting thedata) may include a filename/path for a file/folder containing reviewedparcel data, an indicator whether to repair geometry of the new data(e.g., Boolean value of true or false returned when a system user checksor unchecks a graphical checkbox), an indicator whether to integrate(e.g., Boolean value of true or false returned when a system user checksor unchecks a graphical checkbox), an indicator whether to eliminateduplicate polygons (e.g., Boolean value of true or false returned when asystem user checks or unchecks a graphical checkbox), a text filenamefor a processing log (e.g., to store processing information such as afeature count at critical processing times), and a filename/path foroutput PGDBs 501 with the SDI clone. Other inputs are also contemplated.For example, other inputs may include an employee record ID (RID) thatidentifies the employee executing the script (may be used to populate aCREATE_ID field), a creation date (may be used to populate a CREATE_DTfield), and a resource identifier (which may be used to populate aSOURCE field). In some embodiments, the script may output the new PGDB501 name and an SDI feature class name.

In some embodiments, the script may create a corresponding PGDB 501 inthe designated folder (e.g., with an address provided by the inputs).The script may create an SDI clone feature class 503 in the PGDB 501using the parcel feature class from the master database table as atemplate. Using the parcel feature class from the master database tablemay ensure that the settings and table structure including field namesin the SDI clone will match the parcel feature class stored on adatabase 125 (e.g., a LAN database). If the SDI clone feature class 503already exists in a PGDB 501, the script may proceed to update the nextPGDB 501. This may prevent accidental stacking of objects within a PGDB501.

In some embodiments, multi-part features on polygons of the new data maybe eliminated. The script for converting multi-part to single partgeometries may output a resulting feature class 503 to a temporary PGDB501 (e.g., to minimize space requirements). In some embodiments, themajority of processing may be performed on this temporary feature class.A PGDB 501 may be created prior to executing the script.

In some embodiments, a script may be executed to repair geometries ofthe temporary feature class (e.g., see FIG. 3 and above discussion). Thescript may be executed in conjunction with a check geometry tool (e.g.,used in ESRI) (which, in some embodiments, may create a table containingentries for the features that have invalid geometries). Invalid geometryexamples may include improper ring ordering, short segments,self-intersecting polygons, etc. (which may be defined by a tool inESRI). Check geometry may work with the repair geometries script toindicate which parcel geometries (e.g., polygons) need repairing. Inaddition, in some embodiments, a script may be executed to integrate thetemporary feature class.

As seen in FIG. 4 b, in some embodiments, a street finder script may beexecuted to count voids 453 a,b (e.g., holes in the polygons) to removestreet features 455 and complex polygons from parcel map 451. In someembodiments, the voids 453 a,b in a polygon may be counted and anindicator may be provided for polygons with void counts above athreshold. A high void count may indicate a street feature 455 (e.g., apolygon surrounding a street feature may have multiple voids). Otherpolygons may also have a high void counts (e.g., other polygons withcomplex/auxiliary features). For example, these polygons may have aspider web like appearance. The complex features and/or polygons may bemanually (e.g., by a system user) or automatically removed. For example,if the polygon has a void count greater than a threshold, the polygonmay be automatically removed by the system. In some embodiments, othercriteria may be analyzed when determining whether to remove a polygon.For example, the larger the polygon is, the greater the chance it isassigned to one or more streets. For example, if the polygon has anoverall perimeter greater than 1800 feet, with greater than 10 voids,the polygon may be assumed to be a street polygon. Other perimeters andother void counts are also contemplated. For example, if the area is arural area, a smaller number of voids may indicate a street polygon(e.g., 5 voids for an 1800 foot perimeter). Other criteria may also beused in determining a void/perimeter ratio that indicates the polygonshould be removed. In some embodiments, smaller perimeters with smallervoid counts or larger perimeters with larger void counts may beindicative of a street polygon. In some embodiments, the void count andor perimeter may be displayed to a system user who may then decidewhether to remove the polygon.

In some embodiments, the script may populate the fields (e.g., which maybe associated with attribute data for the parcel data 300) of thefeature class 503. In some embodiments, the script may determine iffields 507 of the temporary feature class already exist (e.g., in theprevious PGDB 501). If so, the existing fields 507 may be reused. Thefields 507 may also be recalculated. For example, a user identifier(CREATE_USER), a creation date (CREATE_DT), a resource identifier(SOURCE), and a status of the data (D_STATUS) fields 507 may be deletedand recalculated. These may be calculated based on the new data. An APN,DUPES, and DUPENUM (DUPES and DUPENUM may be intermediate fields used bya script if the eliminate duplicates graphical checkbox is checked)fields 507 may also be recalculated if they exist for the new data.

In some embodiments, APN, APN2, ADDRESS, PLSSFIRSTDIVISION,PLSSSECONDDIVISION, PLSSTHIRDDIVISION, and OWNER fields (which may bedata fields that hold variables from or calculated from acquired data)may be used. Other data fields may also be used. In some embodiments,scripts may return an error if fields with similar or the same namesalready exist and data within them needs to be verified. These mayinclude the field names used by the parcels feature class from themaster database table. In some embodiments, any data that exists inthese columns may be transferred to the SDI clone feature class. In someembodiments, a script user may be warned that fields exist and dataneeds to be verified prior to appending into the SDI clone. If thesefields exist in the original acquired data, then the fields may have tobe renamed or data within the fields may need to be verified beforetrimming and appending to the SDI CLONE. For example, if originalacquired data contains a field named OWNER and the data does not reflectparcel OWNER information, then this field may need to be renamed so data(which may not be relevant) is not improperly appended to the SDI clone.

In some embodiments, fields 507 may be added and recalculated for thetemporary feature class with data to append. For example, an APN may becreated. CREATE_USER (e.g., a variable to store an employee RID) may bedetermined by data entered in a textbox (e.g., a graphical panelpresented to the system user). Other fields 507 that may be populatedmay include a state identifier (STATE_CODE), a county identifier(COUNTY_CODE), an assessor's parcel number (APN), alternate reference id(APN2), a user identifier (CREATE_USER), a creation date (CREATE_DT), aresource identifier (SOURCE), and a status of the data (D_STATUS) fields507. Additional fields may include a situs address (ADDRESS), astatement of the parcel data's relative spatial accuracy (ACCURACY), thePublic Land Survey System (PLSS) designation, (e.g., PLSSFIRSTDIVISION,PLSSECONDDIVISION, PLSSTHIRDDIVISION), and a property owner (OWNER). Aload date (CREATE_DT) and the original source of the data (SOURCE) mayalso be calculated from inputs, for example, provided to a textbox. Thestatus of the parcel data (D_STATUS) may be calculated from externaldata to reflect data currency (e.g., Current, Archived, etc.). DUPES andDUPENUM may be used in duplicate elimination (and may not be created ifthe indicator whether to perform eliminate duplicates is false).

In some embodiments, the script may further trim and calculate relevantfields in the temporary feature class. The trimming and calculation maybe used to produce data that is both relevant and compatible withcorresponding fields in the parcels feature class from the masterdatabase table stored on a database 125 (e.g., a LAN database) andaccessed through SDI 511. The original APN field 507 may be calculatedby creating a row cursor that loops through the features and performsactions on the individual features within the feature class. If theoriginal APN field has data (e.g., is not empty/NULL), the new APN mayequal the original APN field (which in some embodiments, may have amaximum of 100 characters). In some embodiments, NULL entries (e.g.,empty entries) may be ignored and passed to the SDI clone as NULL. Insome embodiments, the trimming and creating cursor action may berepeated on the fields to be appended. Trimming data may includetrimming data according to a maximum number of characters allowed by acorresponding field in the SDI clone feature class and coincidentallythe parcel feature class from the master database table stored on adatabase 125 (e.g., a LAN database) and accessed by SDI 511. Trimmingmay prevent loading failures caused by trying to put data with more thanthe maximum allowed character length into fields with maximum allowedcharacter settings defined by the parcel feature class from the masterdatabase table field parameters. For example if an original acquired APNvalue has 110 characters and the maximum allowed is 100, then, in someembodiments, only the first 100 characters of the data may betransferred into the corresponding field in the SDI clone feature class.

In some embodiments, if the original APN field has data (not empty), theAPN of the new data may be set equal to the original APN. Empty entriesmay be ignored and passed on to the new PGDB 501 as empty. In someembodiments, fields 507 for these and other variables may be initiallycreated and calculated at a different time in the processing.

In some embodiments, the script may check for duplicate polygons in thetemporary feature class. In some embodiments, the DUPES and DUPENUMfields may be created in the temporary feature class. The geometries ofthe polygons may be compared with a row cursor that loops through thefeatures and may perform actions on the individual features within thefeature class As the script row cursor loops through the rows it mayread the geometries into a list (e.g., in memory), first checking to seeif the geometry already exists in the list. if a geometry does existalready in the list (e.g., as determined by comparing a geometryidentifier (such as an APN) and/or coordinates), then the script mayapply the same value (ID) in the DUPES field 507. The IDs may be readinto a list, and if an ID is already in the list then the ID may beadded to the DUPENUM field 507 for that polygon or else DUPENUM=0. ThisDUPENUM field may be used to apply a series of logical selections todetermine which one of the duplicate geometries to keep and which onescan be deleted. In some embodiments, the logical sequence may includeselecting features with DUPENUM>0. Within this selection, if the APN isempty or if the APNs are equal, DUPES may be deleted. For example, if wehave several equal geometries (duplicate polygons) and they have thesame data, the script may keep one of them and delete the rest. However,in some embodiments, if the APNs are not equal, the script may notdelete the duplicates and a visual review may be used to determine whichduplicate polygons actually have the relevant APN. The other polygonsmay be deleted. Further, the PGDB 501 may be compacted to deleteunnecessary information stored internally by the PGDB file format.Compacting may significantly decrease file size and may be used toensure that there are no failures due to size limitations.

In some embodiments, the temporary feature class 503 with the new fieldsadded, calculated and trimmed, may be appended into the SDI clone. Insome embodiments, appending data processing may use a “NO TEST” rulethat uses a parameter defined by a script (e.g., executing in ESRI) toensure that fields 507 in the temporary processing feature class thatmatch will be transferred to the SDI clone. The other fields 507 that donot have a corresponding match in the SDI clone may remain empty (NULL).In some embodiments, after appending the features to the SDI clone, thetemporary feature class may be deleted and the temporary PGDB may becompacted and refreshed to delete unnecessary information and preventfailures due to size limitations. In some embodiments, the SDI clonefeature class may be integrated. In some embodiments, the SDI clonefeature class may have its geometry repaired with a geometry repairingscript. The geometry repairing script may be used in conjunction withthe check geometry script. In some embodiments, the script may continueto check geometry and repair geometry until the check geometry functionyields 0 features that need repairing (or, for example, a value below athreshold). In some embodiments, the output PGDB may be compacted withthe new features appended to the SDI clone to delete unnecessaryinformation and prevent failures due to size limitations. In someembodiments, a compact disc (CD) may be created with the PGDB 501 withthe new features appended.

At 613, the formatted parcel data 300 may be loaded into the commonformat database 125. In some embodiments, after conversion, parcel data300 from different sources may be loaded into a spatially enableddatabase 125. In some embodiments, the parcel data file may be “dropped”into the application. For example, an icon 201 representing the parceldata 300 may be moved (e.g., using a mouse pointer) over an icon 203representing the common format database 125. Other processes for loadingthe data are also contemplated. For example, the automated loading maybe controlled by a script that points to the file (e.g., through apath/filename) to connect the file to an SDI 511. In some embodiments,the filename of the file to be loaded may be entered by a system userinto a graphical user interface. The SDI 511 may then append the newinformation (which may now be in the same format as the format used forthe other data already stored in the spatial data files of the database125) from the file into the spatially enabled database 125. If the loadfails, the log file 701 may be accessed to determine the error. Theerror may be corrected and the load may be attempted again. Othermethods of determining the error are also contemplated (e.g., an errormessage may be displayed to a system user).

In some embodiments, loading/appending the new data may include theoriginal feature class 503 being replaced with the temporary featureclass 503 that has multi-part features eliminated. The original featureclass 503 from the PGDB 501 may be appended with new fields 507 added,calculated, and trimmed into the PGDB feature class 503 in the otherPGDB 501. In some embodiments, the data may be loaded to the SDI 511.Feature classes may be loaded to the SDI 511. In some embodiments, theAPN, tax identification (ID) number, situs information, mailing address,state, zip code, owner's name, flood zone, elevation of insurableproperty, zoning codes, land use codes, property value, square footage,previous owner's name, utilities, and easements may be stored withassociated parcel data. Attributes may also include a GEO code withlatitude/longitude (e.g., at a centroid of a parcel). Attributes canalso be linked to other types of data. For example, the APN may bestored with a parcel description and be used to separately accessadditional data for the parcel (e.g., from a different database). Insome embodiments, data such as the APN may be accessed from third partydatabases (e.g., as provided by a county).

In some embodiments, for the scripts used in 605-613, if the parcel datafails to pass a stage of the process, the data may be reviewed again(e.g., see 603). If the problem persists, the parcel data acquisitionmay be reported as incomplete.

In some embodiments, the scripts may be executed in a predeterminedmanner to increase efficiency and, for example, prevent executing ascript multiple times during conversion. For example, the explode scriptmay be executed before the eliminate duplicate geometries script toavoid duplicate geometries that may be created as a result of theexplode script. As another example, the eliminate duplicate parcelgeometries may be performed prior to the repair geometries script whichmay be performed prior to the integrate parcel geometries script.

In some embodiments, the sequence of the scripts may follow aprogression of spatial data organization. For example, as seen in FIG. 7a, a feature class 503 may contain features that contain polygons thatinclude geometries (e.g., which may be described in parcel coordinates711). The polygons may also have associated attributes 713. The logicalorder for the scripts may start with individual geometries. For example,an initial script may make one or more geometries (e.g., polygons)independent (e.g., the individual geometry (polygon) may now be aseparate feature with its own attributes). In some embodiments, this maybe done by eliminating multi-part features to give each geometry (e.g.,in the database 125) an independent feature with its own attributes. Forexample, multi-part polygons may be converted into single part polygons.A subsequent script may examine the geometries of these independentfeatures to determine if problems exist. The problems may then berepaired using additional subsequent scripts. It may be more efficientto repair the geometries after multipart geometries have been corrected(e.g., to prevent needing to run the repair script again after theeliminate multipart script if the eliminate multipart script is runafter the initial repair script). An integrate script may analyze thefeature class to determine if nodes of the feature class are within thecluster tolerance (and then may be removed). In some embodiments, it maybe more efficient to execute the integrate script (which looks at theinteraction between polygons) after the repair script to avoid needingto run the repair script and then integrate script again if an error isfound while executing the initial integrate script. Trimming scripts anddata loading scripts may then be used on the integrated data. In someembodiments, it may be more efficient to execute format and/orconcatenate relevant/available attribute data after integrate scriptand/or repair script in case a polygon feature needed to be eliminatedor fixed prior to formatting (e.g., to enable the polygon to be fixedprior to being associated with attributes). In some embodiments, columns715 and spatial indices 717 may also be used to organize the data in thefeature class. Spatial indices 717 may be row identifiers or otheridentifiers (e.g., created by the database software for use by thedatabase software) to organize the parcel data in the feature class 503.In some embodiments, it may be more efficient to append parcel dataafter extraneous polygons are eliminated.

As seen in FIG. 6 b, in one embodiment, the ordering of scripts mayinclude scripts executing to:

At 651, determine spatial accuracy,

At 653, project data,

At 655, convert shape-file 703 to PGDB class (if needed),

At 657, recheck spatial accuracy,

At 659, explode,

At 661, repair geometries,

At 663, integrate data,

At 665, format and/or concatenate relevant/available attribute data,

At 667, eliminate duplicate geometries,

At 669, append data to a temporary feature class,

At 671, integrate data,

At 673, repair geometries, and

At 675, load data into the common format database 125 (e.g., a spatiallyenabled database). In some embodiments, repair geometries may beperformed prior to loading the data to prevent failures to load due toinvalid geometries. Other scripts and orders for the scripts are alsopossible. In some embodiments, it should be noted that in variousembodiments of the methods described in FIG. 6 b, one or more of theelements described may be performed concurrently, in a different orderthan shown, or may be omitted entirely. Other additional elements mayalso be performed as desired. Parts or all of the process shown in theflowchart of FIG. 6 b may be automated (e.g., performed by a computersystem).

In some embodiments, multiple scripts may be performed at approximatelythe same time. For example, a system executing the scripts maymulti-thread the scripts. In some embodiments, the scripts may berecursive scripts. In some embodiments, a script may be used to linkmultiple scripts in the predetermined manner. For example, one scriptlinking other scripts may automate the scripts used to clean-up parceldata 300.

As seen in FIG. 7 b, in some embodiments, parcel data 753 may be updatedin the database 125 by replacing parcel data 753 in the database 125with new parcel data 751. In some embodiments, data associated with theparcel data (e.g., persisting parcel data 757) may be retained even whenthe parcel data 753 is updated. For example, the parcel data for one ormore parcels may be subdivided and the subdivided parcels may receivenames, indicators, etc. For example, a parcel of a shopping mall may besubdivided into the various store lots included in the shopping mall.These subdivisions may receive names or indicators of the associatedstores. As another example, a parcel for a set of condominiums may besubdivided to indicate the location of specific condominiums and anowner name, etc. may be associated with respective subdivided parcels.The subdivisions and names/indicators may persist in the database 125when the overarching parcel data 753 is updated. In some embodiments,the subdivisions may be adjusted to fit updated parcel data 755. Thesubdivisions, etc. and the adjustments may be provided manually (e.g.,by a system user) and/or automatically by a computer system.

Other data 757 may also be persisted during updates (e.g., parcel names,research points, flood zone change detections (e.g., noted detecteddifferences between a previous flood zone status for a parcel and acurrent flood zone status), and other data associated with the parcelthat may still correspond to the parcel even after an update). Asanother example, parcel data 753 may be edited (e.g., by a system useror computer system) and the edits may be persisted. For example, aparcel geometry that was removed prior to the update may be removed fromthe updated parcel data 755. Other edits to persist are alsocontemplated. In some embodiments, the data to be persisted may bestored in a separate database 125 and/or may be marked or tracked (e.g.,through a log file 701) in the parcel database 125. The data to persistmay then be preserved when the new parcel data 751 is used to replacethe previous parcel data 753.

In some embodiments, a tracking application may be used to track thestatus of data sources for the parcel data 300. For example, the statusmay include an availability (e.g., to indicate the data is alreadyin-house (i.e., currently available), the data can be acquired from asource at low cost, the data can be acquired from a source at high cost,and the data is not available). The tracking application may be used tokeep track of the changing status of the data sources (e.g., datasources that become newly available). The tracking application can alsotrack the type and quality of the data available and/or being added tothe common format database 125 (e.g., whether the data from a particularsource will require a lot of work to repair, etc.). Quality may includeno correction needed, minor correction needed, moderate correctionsneeded, and unusable. Other qualities are also contemplated. In someembodiments, the quality may be represented by a quantitative “accuracy”factor (e.g., assigned according to a set of criteria). Type may includeraster data or vector data. Other types are also contemplated. Trackingthe data sources may also include receiving an indication that a statusof the data source has changed (e.g., from available at low cost changedto available at a high cost). Tracking the state of the data may allowthe common format database 125 to be updated when needed. For example,if the state of a portion of data indicates the portion is out of date(because of a new data revision), the portion of data may be replacedwith the updated portion. In addition, tracking the state of the datamay allow an entity to determine where to access data that is notalready in the common format database 125. For example, the state mayindicate the data is available through company X.

FIG. 8 illustrates a flowchart for a method of tracking the status ofthe data sources, according to an embodiment. In some embodiments, itshould be noted that in various embodiments of the methods describedbelow, one or more of the elements described may be performedconcurrently, in a different order than shown, or may be omittedentirely. Other additional elements may also be performed as desired.Parts or all of the process shown in the flowchart of FIG. 8 may beautomated (e.g., performed by a computer system).

At 801, a status of a first parcel data source may be determined. Insome embodiments, the status of the first parcel data source mayindicate at least an availability of data access (e.g., availability mayinclude currently available, low cost acquisition, high costacquisition, or not available) from the first parcel data source. Insome embodiments, the status of the first parcel data source mayindicate a type of data (e.g., raster or vector) of the first parceldata source. The status may also indicate a quality of the data (e.g.,no correction needed, minor correction needed, moderate correctionsneeded, or unusable) from the first parcel data source.

In some embodiments, the status may be received from the first parceldata source (e.g., in data from the first parcel data source),determined from other information associated with data from the firstparcel data source (e.g., data included in metadata with the data fromthe first parcel data source), or entered manually. For example, agraphical user interface may be provided for entry of the status of thefirst parcel data source (e.g., to be entered by a system user). Othermethods of determining the status of the first parcel data source arealso contemplated.

At 803, a status of a second parcel data source may be determined.

At 805, the status of the first parcel data source and the status of thesecond parcel data source may be automatically stored (e.g., in thecommon format database). For example, the status of the first parceldata source may be stored as a relationship associated with the firstparcel data source. Additional relationships may also be determinedand/or stored. For example, relationships may include a type of resourceassociated with the data source, a media type of the data source, or asystem user associated with the data source (e.g., assigned to processthe data source). In some embodiments, storing the status of the firstparcel data source may include storing the status of the first parceldata source in a resource inventory. Storing the status of the firstparcel data in the resource inventory may include storing information ona source of the first parcel data and a cost associated with the firstparcel data. Other information may also be stored in the resourceinventory (e.g., legal restrictions associated with the use of the data,associated website address, property access legal information, and otherinformation on the data source).

At 807, parcel project description data may be received from a systemuser through a graphical user interface. The parcel project descriptiondata may include at least one task. The task may include, for example,acquire the parcel data, update the parcel data, clean-up the parceldata, etc.

At 809, an entity assignment for the at least one task may bedetermined.

At 811, a first entity for the at least one task assignment may benotified (e.g., through an electronic mail message). Other notificationsare also contemplated.

At 813, an indication of a change in status of the first parcel datasource or a change in status of the second parcel data source may bereceived (e.g., through a data transmission or from a system user). Forexample, the change in status may include a change in availability,quality, or type.

At 815, the indication of the respective change may be stored (e.g., inthe resource inventory).

In some embodiments, the tracking application may track the legalaspects surrounding data in the common format database 125 and fromexternal sources. For example, the tracking application may trackwhether data is copyrighted, protected under a non-disclosure agreement,or free for general use. The tracking application may track whichportions of data can be made available to the public and which portionsare protected. For example, a general plat map of a parcel may beavailable to the public but a flood risk assessment may be protected. Insome embodiments, the common format database 125 may be made availableover the Internet (e.g., unrestricted portions may be made available).In some embodiments, a web interface may be provided to allow differententities to access the data (e.g., on a subscription basis). In someembodiments, the database 125 may be stored on a storage medium (e.g., aCompact Disc) and the storage medium may be offered for sale or lease.

In some embodiments, a tracking application may be used to track whichsystem users are assigned to specific tasks. For example, the trackingapplication may be used to assign a data conversion/loading processingtask to a system user, view the current assignments, change/editassignments, etc. Data conversion/loading processing tasks may include,for example, order data from a source, review data, prepare data, putdata in a Geographic Information System (GIS), etc. Other types ofprojects and tasks are also contemplated. For example, projects mayinclude a flood risk assessment. The tracking application may receiveparcel project description data (e.g., including at least one task toperform on the data) from a system user through a graphical userinterface, determine an entity assignment for the at least one task, andnotify a first entity (e.g., a system user) of the task assignment. Insome embodiments, the tracking application may include one or morecooperating applications. For example, one application may track dataacquisition (including nationwide contacts for the data, GIS processing,etc.) and one application may manage the workflow for the dataacquisition (e.g., assigning tasks to specific system users). In someembodiments, tracking data acquisition and managing the workflow may beperformed by the same application.

In some embodiments, tracking data (e.g., including information on thesource, availability, contact list, legal aspects, workflowcharacteristics, etc.) may be stored as metadata associated with thedata. For example, a series of numbers may be used in the metadata torepresent different characteristics associated with the data. Otherinformation may also be stored in the metadata (e.g., information on howto manage data from sources smaller than a county, etc.).

FIG. 9 a illustrates a panel 900 for creating a project to be assigned,according to an embodiment. In some embodiments, the project may becreated and managed by a tracking application. Information about theproject may be entered into the tracking application. For example,project name 901, frequency of the project 903, related projectidentification (ID) 905, effective date 907, due date 909, received date911, delivery date 913, assigned to entity 915 (e.g., an employee numberof the employee assigned to the project), research access identifier916, notes 917, point type 919, parcel object count 921 (e.g., a numberof objects associated with a particular data set), address data count923, APN count 925, owner name count 927, and indicators for addressdata, APN, and owner name (e.g., which may indicate whether theinformation is available). For example, for a county parcel layer, eachparcel polygon within the county may include an object. The APN count925 may include a number of the objects that have an assigned APN. Theaddress data count may include a number of objects with addressesassigned. Owner name count 927 may include a number of objects withowner names assigned. In some embodiments, the due date 909 may includea date the task is due, effective date 907 may include a date assignedto the data, received date 911 may include a date the data was received(e.g., into the system), and delivery date 913 may include a date thetask was completed. Other date are also contemplated.

An icon 929 on the screen may be clicked to add the project once thedata (or part of the data) is entered. Frequency of the project 903 maybe, for example, how often data from a particular resource is updated.The research access identifier may indicate whether the data was createdby research or from an external source.

FIG. 9 b illustrates a panel 951 for adding tasks to the project,according to an embodiment. A drop down menu 953 may be accessed toindicate project options. For example, “Add Task” may be selected tobring up a data entry panel for adding date respective to a task to beadded to the project. Other selection tools may also be used to indicateproject options (e.g., clicking on an icon). Data fields may bepopulated by a system user to indicate information about the task to beadded. In some embodiments, some of the data fields may be pre-populatedwith data entered for the project (see FIG. 9 a). Information about atask to be added may also be provided (e.g., by entering a taskidentifier into a data entry panel) in a panel (e.g., similar to thepanel in FIG. 11). Other information may also be entered about the tasks(e.g., a deadline, task type, etc.).

FIG. 9 c illustrates a panel 970 for viewing tasks of the project,according to an embodiment. For example, “View tasks” may be selectedfrom the drop down menu 971. FIG. 10 illustrates a resulting panel 1000listing tasks 1001 of the project, according to an embodiment. Forexample, three tasks are listed with task identifiers 1003 (e.g.,“1070396”). The task information may also include a task code 1005, taskname 1007, task status 1009, status date 1011, and assigned to notes1013.

FIGS. 11 and 12 illustrate panels for editing details for a task,according to an embodiment. The status of the tasks 1101 may also beupdated using the data entry screen shown in FIG. 11. For example, adrop down menu 1103 may, for example, be used to select “In Progress” or“New”. In some embodiments, a system user may open tasks at drop downmenu 1103 to change status and add notes as the project progresses. TheTask status data entry panel 1100 may be provided by the trackingapplication after, for example, double clicking the task name in the“View tasks” data entry panel 1000. Other information may also beedited. For example, the task type 1105, the assigned to entityinformation 1107, notes 1111, special instructions 1109, etc. Changingthe assigned to entity information 1107 may result in an electronic mailmessage 151 being sent to the new entity responsible for the task aswell as an electronic mail message 151 to the previous entity assignedto the task. In some embodiments, the entity may be an employee or maybe a computer system.

FIG. 13 illustrates a panel 1300 for adding a resource (e.g., a possiblesource of parcel data), according to an embodiment. In some embodiments,information may be maintained about acquired data. For example, thesource of the data, the cost of the data, the state of the data,restrictions on data usage, etc. The panel may show several dropdownmenus (e.g., for application view 1301, extent type 1303, and mediaformat 1305) (other selection mechanisms are also contemplated). In someembodiments, a parcel inventory application and a resource inventoryapplication may both access the same data tables in the database 125.For example, application view may be used to indicate which application(parcel inventory, resource inventory 513, or both) should have accessto and display the associated data when searched (e.g., see FIGS.20-24). In some embodiments, parcel inventory and resource inventory 513may be separate databases and application view may be used to indicatewhich database 125 should receive the parcel data 300.

In some embodiments, parcel data 300 that exists, but has not yet beenacquired (e.g., through purchase or lease) or parcel data 300 that hasbeen obtained but has not yet been loaded into the common formatdatabase 125, may be viewable in a parcel inventory through a parcelinventory application (i.e., “Parcel” 1301) (e.g., see the parcelinventory search and results panel in FIGS. 20-21). Once parcel data 300is loaded, it may remain in the parcel inventory (“Parcel”) and be mayalso be viewable in the resource inventory 513 (i.e., “Research” 1301)(e.g., see the resource inventory search and results panel in FIGS.23-24). Some parcel data 300 may exist but not have a relationship tothe parcel inventory. This data may be viewable in the resourceinventory 513. For example, data viewable in the parcel inventory mayinclude parcel data 300 that can be purchased or leased. Items viewablein resource inventory 513 may include website addresses for parcelviewing (which may not allow downloads), property access legalinformation, and contact info for counties or communities. Other data isalso contemplated. The resource inventory 513 may include data usefulfor performing flood zone determinations. in some embodiments, theparcel inventory may combined with the resource inventory.

In some embodiments, a Uniform Resource Locator (URL) field 1307 andcompany label field 1309 (e.g., URLs or company sources of data) may beprovided for respective information. There may also be a list ofresource or data types. For example, parcel 1311, legal 1313, aerial1315 (e.g., aerial maps), street 1317 (e.g., street maps), and contact1319 may be used to indicate the type of data entered into the panel.The data may be entered manually or may be captured from the data ordata source (e.g., read from an incoming file to be appended to a commonformat database 125). An “Add Resource” icon 1321 may be selected tosubmit the entered information.

FIGS. 14-15 illustrate panels (e.g., empty panel 1400 and partiallypopulated panel 1500) for editing the resource, according to anembodiment. Information may be added and edited for a resource. Forexample, view type 1401, extent type 1403, media format 1405, whetherconcealed 1409, data types (such as parcel 1419, legal 1411, aerial1413, street 1415, contact 1417), URL 1421 (Uniform Resource Locator),URL secure 1423, leased 1425, concealed 1409, subscription costs 1427,frequency 1429, received date 1431, company/office/department label1432, phone numbers 1433 and 1435, fax number 1437, email 1439, addresslines 1441 and 1443, city 1445, state 1447, zip code 1449, supplyinformation 1451, provided information 1453, availability information1455, created date 1461, created by field 1463, edit date 1465, edit byfield 1467 and comments 1457. In some embodiments, this screen mayappear after the add a resource screen (shown in FIG. 13). In someembodiments, the whether concealed box 1409 may be checked (or otherwisereceive an indication) to prevent the resource from being displayed incertain applications (e.g., the resource inventory 513 and parcelinventory). The data may then be concealed from general view but madeavailable if needed. This option may be used, for example, if a resourcebecomes outdated, has a problem, or is incorrect.

In some embodiments, hyperlinks 1407 (e.g., “Rel #: 0”) may be includedto add detail on other screens. For example, data for particular countydata sets may be captured on other screens by clicking the hyperlink todisplay the other screens. Data for a resource may be entered manuallyor captured from the data or data source (e.g., from a file with theresource). A save resource icon 1459 may be clicked to save the updatedinformation.

FIGS. 16 a-b illustrates panels 1601 and 1603 for county resourcerelationships, according to an embodiment. Relationships may includeresources, processing system users, and/or other information linked toparcel data. For example, a relationship may be defined in the systemfor parcel data to show information on the source of the parcel data. Arelationship may also be set up for the parcel data to show informationon an employee or other entity assigned to process the parcel data.

In some embodiments, county relationships may be entered into the systemthrough county resource relationship data entry panels 1601 and 1603.Relationships may also exist at other levels (e.g., community, city,state, national, etc.). Relationships may also be assigned to resources.In some embodiments, resources may have more than one relationship.Resources may include information on sources of parcel data 300, legaldata, aerial data, street data and vendor contact data. Other resourcesare also contemplated. As an example, vendor contact data may be enteredas a resource and the counties (data sets) for which the vendor has datamay be entered as relationships to that resource. In some embodiments,common attributes for the data sets (e.g., relating to contactinformation for the vendor who provided the data sets) may be assignedto these data sets. In some embodiments, the resource and relationshipdata may be maintained as two separate tables in the common formatdatabase 125. In some embodiments, the resource and relationship datamay be maintained in the common format database 125.

In some embodiments, the county relationships may be entered after theresource is edited (e.g., as seen in FIGS. 14-15). The panels 1601 and1603 may include resource ID 1605, media format 1607, extent type 1609,relationship number 1611, state 1615, county 1617, and information aboutthe data from that county 1619 (e.g., data already in the common formatdatabase 125). Relationship number 1611 may represent the number ofrelationships associated with a particular resource (e.g., with“Resource ID: 16419” 1605).

In some embodiments, the state 1615 may be entered first and then acounty dropdown menu 1617 may be provided for the system user to selecta county. Other dropdown menus or graphical inputs are also possible.For example, if the Extent Type 1303 (shown as extent type 1609) isselected as “Community”, the dropdown menu 1617 may provide FEMAcommunity names for selection. In some embodiment, selection of a FEMAcommunity may result in storing the associated FEMA number to the FEMAcommunity in the common format database 125.

In some embodiments, existing relationships may be listed at the bottomof the data entry panels 1601 and 1603. As seen in FIG. 16 b, once thecounty is selected, a hyperlink “Add Relationship” 1621 may appear tolink to the next screen.

FIGS. 17-18 illustrate panels 1700 and 1800 for adding a countyrelationship, according to an embodiment. In some embodiments,information about a county relationship may be added. Pre-populatedinformation may include resource ID 1701, FIPS (Federal InformationProcessing Standard) code 1703, media/format 1705, and extent 1707.Other information may also be pre-populated. Information may also beeditable. For example, priority indicator 1709, access type 1711 (e.g.,indication of one or more databases (such as research or parcel) toprovide access of the parcel data to), search by field 1713, year 1715,research notes 1717, data availability status 1719, GIS project ID 1721,purchase cost 1723, lease cost 1725, setup cost 1727, and update cost1729. Restrictions may also be included. For example, indicator boxesfor can modify 1731, known agreement 1733, and can resale 1735 may beused. Additional information may include has address 1737, has ownername 1739, held from research 1741. Notes 1742 may also be added. A“Submit” icon 1743 may be selected when the system user is finishedentering known information into the fields. For example, panel 1800shows some of the fields have been populated. A “Cancel” icon 1745 mayalso be used to cancel the panel 1700/1800. The data may be enteredmanually or captured from the data or data source. The entered data maybe linked to a resource (e.g., a resource with information entered inthe panel of FIG. 13).

FIG. 19 illustrates a panel 1900 for listing a county resourcerelationship, according to an embodiment. The panel from FIG. 16 b isshown with the added relationship 1901. The information may be edited orremoved by clicking the respective indicator. Additional counties andassociated information may also be added (and may correspondingly bedisplayed on the listing).

FIGS. 20 a-b illustrate panels 2000 and 2002 for parcel inventorysearches, according to an embodiment. Data may be entered (or otherwiseindicated) in a parcel inventory search panel 2000. For example, state2001, county 2003, media format 2009, and data status 2011 may beentered to search a common format database 125 for the respectiveinformation. In some embodiments, a county 2003 dropdown menu may bepopulated when the state 2001 is selected (e.g., on the state 2001dropdown menu). In some embodiments, the search may be focused on datastatus such as not available, available, pending load to GIS (e.g., forprocessing), or loaded to GIS. “Address” 2005 and “Owner” 2007 boxes maybe provided to limit the search to records that have an address orowner's name. Other types of data entry are also possible (e.g., entryfields, icons, etc.). A “Submit” 2013 icon may be used to submit thedata when the fields have been populated. A “Reset” 2015 icon may beselected to reset the fields (e.g., blank the fields).

FIG. 21 illustrates a panel 2100 for parcel inventory search results,according to an embodiment. Inventory results may be returned aftersearching the entered criteria. For example, parcel data 2101 for acounty in a state may have been located.

FIG. 22 illustrates a panel 2200 of parcel resource detail, according toan embodiment. Information about a parcel resource may be displayed. Forexample, the search result from FIG. 21 may be selected by clicking therespective ID number 2103 (which may be a hyperlink to the relevant datashown in panel 2200). The data for the parcel data may be displayed. Thedisplayed data may have been entered through the data entry panelsshown, for example, in FIGS. 13-18.

FIG. 23 illustrates a resource inventory search panel 2300, according toan embodiment. In some embodiments, data may be entered (or otherwiseindicated) in the resource inventory search panel 2300. For example,state 2301, county 2303, keyword 2321, nationwide data search indicator2305, contact data search 2307, and off site data search 2309. A searchicon 2323 for searching may also be provided to indicate a search basedon the entered criteria. A load resources icon 2311 may also be providedto load resources for searching. An information bar 2313 may be providedwith codes used in the search results. Box 2315 may indicate no resultshave been found (this may be the default when search criteria is firstentered).

FIG. 24 illustrates a resource inventory results panel 2400, accordingto an embodiment. In some embodiments, research results 2315 may includeresults from a search based on information entered in the top searchfields (e.g., 2301, 2321, 2303, 2417 (“Community” field), 2305, 2307,and 2309). The results may include a type of resource (e.g., parcel,legal, aerial, street, free site, and contact), media type, coverageindicator, panel links, company name, year, search by criteria, notes,and ID. Other results may also be provided.

FIGS. 25 a-b illustrate a workflow interface 2501 a,b for management ofparcel data 300, according to an embodiment. For example, the workflowinterface 2501 a,b may be used to manage raw parcel data 300 in thesystem. The workflow interface 2501 may track a status of datasetsreceived (e.g., a dataset may include a collection of parcel data 300from counties, communities, and vendors) as the datasets are processedthrough data collection and processing. For example, the workflowinterface 2501 may be used to provide information on the datasets priorto being received into the system until the processed data is loadedinto the spatially enabled database 125. In some embodiments, the columnheaders (e.g., column headers 2503 a,b, etc.) on the SDI Status Monitorinterface 2501 may represent a status (e.g., unknown, unavailable,available, ordered, received, validated, in progress, staged, loaded,etc.) that a relationship (for the parcel data 300) can be assigned(e.g., by the system or by a system user interfacing with the system).In some embodiments, the data may be viewed by selecting an extent type(e.g., state, county, city, community, etc.) from a drop down menu 2505.Other selection mechanisms are also contemplated. In some embodiments,the workflow interface 2501 may provide information on how many datasetsof certain types are assigned to an employee 2507 (or otherindividual/entity). For example, “Employee 9” (which may be replaced byan actual name) may be assigned 1 received dataset and 2 in progressdatasets. In some embodiments, clicking on the actual number under thecolumn header 2503 may provide information on the datasets included inthe number (e.g., see FIG. 29). In some embodiments, the system userassigned to process the dataset may be stored in the system as arelationship (e.g., an employee identifier may be stored as arelationship associated with the dataset).

FIG. 25 b illustrates a community portion (see drop down menu 2505) of aworkflow interface 2501 b. In some embodiments, data may be managed on acounty level, community level, etc. within the spatially enableddatabase 125 (other levels are also contemplated). For example, parceldata 300 may be received from smaller “communities” within a county.Therefore, a larger “county” dataset may include numerous smallerdatasets. The smaller communities may be assigned independentrelationships and managed and tracked by the workflow interface 2501 asseparate units within the county. Similarly, data may be tracked asseparate county units within a state or residential units within ablock. Other units of management are also contemplated. In someembodiments, the parcel data 300 for the smaller communities may thus beassigned relationships associated with the smaller communities.

FIG. 26 illustrates a resource summary interface 2601, according to anembodiment. In some embodiments, the resource summary interface 2601 mayprovide information (e.g., from information stored on a database 125)about the source of data for a dataset. For example, the resourcesummary interface 2601 may include a provider information section 2603with contact information for ordering and/or updating a data set (e.g.,company 2605) and an identity of a source of additional informationabout these datasets (e.g., the contact name 2607 of a person/entity whocan be contacted for additional information). In some embodiments,multiple relationships (e.g., dataset sources, update sources, etc.) maybe assigned to a resource. The relationships may include information onthe actual dataset received (or, for example, a dataset that isavailable) from a source (e.g., the county). In some embodiments,information may be stored and/or provided for resources that trackschanges made to the resource, when the changes were made, and by whatsystem user. Other information may also be stored/provided for aresource. Resources may be given a unique resource identifier (e.g.,“Rsrc ID: 16634”) as shown in FIG. 26. Other resource identifiers andresource identifier formats are also contemplated. In some embodiments,information may be maintained about creation and edit dates/entities forthe dataset and/or resource (e.g., created date/time 2609 and creationentity 2611 (e.g., an employee number)).

In some embodiments, other actions for the resource summary interface2601 may be selected from a drop down menu 2613 (or other selectionmechanism). For example, a system user may choose to view otherinformation about the dataset, to modify information about the dataset,and/or to modify the dataset. Other actions are also contemplated.Hyperlinks (e.g., resource results 2615 and search again 2617) may alsobe provided to link to other information and/or actions for the dataset(e.g., to search for another dataset).

FIG. 27 illustrates a resource relationship summary 2701 for a county,according to an embodiment. The resource relationship summary 2701 mayprovide a summary for relationships that exist for a county (e.g.,“AnyCounty” (which may be a county in the United States or other part ofthe world)) or other geographical descriptor (e.g., community, city,state, etc.). In some embodiments, the resource identifiers (e.g.,resource identifier 2703) may be provided. For example, in theembodiment illustrated in FIG. 27, two of the relationships for thecounty belong to “Resource 16634”, which may be, for example, the CountyAssessor's Office (as seen in FIG. 26). Also, as seen in thisembodiment, another relationship for the county may include a thirdcompany that is also a source of parcel data 300 for this county. Otherinformation may also be provided (e.g., relationship identifier 2705,state 2707, FIPS 2709, coverage 2711 (e.g., county name), company 2713(or other source), status 2715, owner 2717, media 2719 (e.g., filetype), extent 2721, WF 2723 (Workflow priority), Hsng# 2725 (Housingunits for the county as reported by the US Census), Vol# 2727, Man#2729, year 2731, and location 2733). In some embodiments, Vol# and Man#may include numbers that are generated to represent the total ordervolume (e.g., flood risk assessment orders for a company processing theparcel data 300) and manual volume experienced in these counties in thepast 365 days. Other units (e.g., city, state, etc.) and other timeperiods (e.g., month, week, etc.) are also contemplated. Vol# and Man#may be calculated continuously by the system to remain current.

In some embodiments, the status field 2715 may indicate which data setis active within a workflow (e.g., with an identifier of “Loaded”). Astatus identifier of “Obsolete” may indicate datasets that are no longerin the workflow and either represent an “old” dataset, or a dataset thatwas never acquired due to cost, legal restriction, or other variablesevaluated by management. Other status identifiers are also contemplated.The resource relationship summary 2701 may enable a system user (e.g.,management) to track received datasets and sources of data update (e.g.,for a particular county). In some embodiments, parcels (e.g., processedthrough GIS scripting) from these datasets may include a link to theparcel's respective relationship identifier 2703. The link for eachparcel may thus provide information on the source for the parcel (e.g.,the dataset the parcel was derived from and/or the source of thedataset).

FIG. 28 illustrates an edit relationship summary interface 2801 for aresource (e.g., for a relationship assigned to the resource 16634),according to an embodiment. In some embodiments, information about aparticular dataset may be stored as a relationship with the dataset. Insome embodiments, the information for these datasets may include status2805, cost to acquire 2807, vintage date 2809 (or current as of date),and legal notes 2811, combined with other legal information field.Status 2805 may include a dropdown menu that reflects the various columnheaders on the SDI Status Monitor 2501 (e.g., FIGS. 25 a-b). Otherselection mechanisms are also contemplated. In some embodiments, creditstatement 2899 may be used to include a citation for the source of thedata (e.g., if a citation is required by the county). The creditstatement 2899 may be included within metadata that follows the relevantdataset. As seen in the interface 2801, other information may be editedand/or derived from the dataset or source of data for the dataset. Forexample, main information 2813 may include relationship identifier,county, price (e.g., purchase price, leased price, setup price, updateprice), date (e.g., available date, ordered date, received date, loadeddate), frequency (e.g., frequency of updates), vintage date 2809 (e.g.,the date associated with the dataset), amount paid, WF priority, status,and employee identifier. Parcel information 2815 may includeavailability indicators (e.g., address, owner name, APN, etc.), presenceof an easement, housing unit, order volume, manual volume, dataprojection, and notes. GIS information 2817 may include object number,APN number, address number, owner number, and notes. Researchinformation 2819 may include URL extension, location, priority, searchby terms, and notes. Legal information 2821 may include indicators forhas agreement, can modify, can resale, can use, review, verbalconfirmation, and notes and credit statement 2899. Other information mayalso be included. For example, other information 2823 may includecreated date, edit date, created by identifier, and edited byidentifier.

FIG. 29 illustrates a resource relationship summary 2901 for anindividual (e.g., an employee), according to an embodiment. In someembodiments, the summary 2901 may be displayed, for example, by clickinga linked number on the SUI Status Monitor 2501 (FIGS. 25 a-b). Clicking(or in some other way accessing the number) may result in a display ofthe relationships for a particular status that are assigned to anindividual. These items may be sorted by any of the column headerslisted above. A sorting mechanism for the relationships may includeincreasing Workflow Priority and decreasing housing number (e.g.,housing units for the county as reported by the US Census). Othersorting mechanisms are also contemplated. The resource relationshipsummary 2901 for the individual may include resource identifier,relationship identifier, state, FIPS, coverage, company, status, owner,media, extent, workflow priority, housing number, volume number, andmanual volume. Other information may also be included. In someembodiments, the relationships may represent an item within a workflowfor the parcel data 300 from the creation of the parcel data 300. Theproject status of the parcel data integration may be determined by thestatus of the relationship. In some embodiments, available relationshipsmay be evaluated by a system user to determine what parcel data 300should be acquired and when. In some embodiments, evaluating therelationships to determine what parcel data 300 should be acquired andwhen may be automated.

FIG. 30 illustrates a resource inventory search interface 3001,according to an embodiment. In some embodiments, a search category maybe included for the resource inventory 513. While the “Parcel Inventory”may be used to document and track Vector (GIS) parcel resources, theparcel inventory may be a component of a larger Resource inventory 513.In some embodiments, the parcel inventory and the resource inventory 513may be one inventory. The search interface 3001 may include severaloptions. For example, a system user may enter the resource identifier orrelationship identifier if known. In some embodiments, a dropdown menu3003 for media type may be used to differentiate Vector from other typesof resources. Dropdown menu 3003 may be used to search for a particularmedia type of resource. An extent dropdown menu 3005 may include countyor community (or another extent identifier). State drop down menu 3007may include options for the state. In some embodiments, check boxes 3009a-e may be used to search Vector parcel data (among other types ofparcel data 300). Location drop down menu 3011 may include a physicallocation of a hardcopy resource (or, for example, the location of astored copy of the resource). URL 3013 and Company 3015 search fieldsmay be used to search URLs and companies associated with the datasets.The status drop down menu 3017 may allow searches for resources with aspecified status.

FIG. 31 illustrates a flowchart for purchasing and incorporating data,according to an embodiment. In some embodiments, it should be noted thatin various embodiments of the methods described below, one or more ofthe elements described may be performed concurrently, in a differentorder than shown, or may be omitted entirely. Other additional elementsmay also be performed as desired. Parts or all of the process shown inthe flowchart of FIG. 31 may be automated (e.g., performed by a computersystem).

At 3101, data may be requested.

At 3103, contact information may be entered into a parcel inventory(e.g., see FIG. 13).

At 3105, a cost sheet may be generated (e.g., with costs associated withthe requested data).

At 3107, a determination may be made whether to purchase the data.

At 3109, if the data is not to be purchased, the process may end.

At 3111, if the data is to be purchased, a GIS project may be initiated.

At 3113, the data may be received.

At 3115, the data may be downloaded and a back-up copy of the data maybe made (e.g., on a compact disc (CD)).

At 3117, resource tasks may be closed.

At 3119 control may be transferred to GIS.

At 3121, the data/project may be received in GIS for processing (e.g.,according to the scripts described herein).

FIGS. 32 a-d illustrate a flowchart for assessing a legal status ofacquired data, according to an embodiment. In some embodiments, itshould be noted that in various embodiments of the methods describedbelow, one or more of the elements described may be performedconcurrently, in a different order than shown, or may be omittedentirely. Other additional elements may also be performed as desired.Parts or all of the process shown in the flowchart of FIGS. 32 a-d maybe automated (e.g., performed by a computer system).

At 3239, a community may be identified for potentially acquiring parceldata 300. At 3241, a determination may be made whether digital parceldata 300 is currently in the common format database 125. If the data isnot currently in the common format database 125, flow may proceed atFIG. 33.

At 3243, the source of the data may be identified. If the data is from aprivate source, a determination may be made at 3259 whether there is anagreement with the vendor that provided the data. If there is anagreement with the vendor, a determination may be made at 3261 whetherthere are any restrictions on the use of the data. If there are not anyrestrictions on use, at 3257, the data may be used. If there arerestrictions on use, at 3275, a determination may be made whether thevendor can be contacted. If the vendor cannot be contacted, at 3299,vendor contact information can be researched.

From 3259, if there is not an agreement with the vendor, at 3273,determination may be made whether the vendor can be contacted. If thevendor cannot be contacted, at 3271, vendor contact information can beresearched.

From 3275 and 3273, if the vendor can be contacted, at 3285, adetermination may be made whether a negotiation with the vendor on usingthe data (either to discuss a potential agreement or the restrictions ofan existing agreement) was successful. If not, at 3287, the data may notbe used. At 3293, if the negotiation is successful (e.g., a favorableagreement is reached), the data may be used.

At 3245, if the data is public (see 3243), a determination may be madewhether the data is copyrighted. If the data is copyrighted, at 3215, adetermination may be made as to what part of the data is copyrighted. At3213, a determination may be made whether the copyright affects the useof the data in the database 125. At 3211, if the copyright affects theuse of the data in the database 125, applicable copyright laws(state/federal) may be reviewed for a possible solution.

At 3247, a determination may be made whether there is an agreement withthe community regarding the data (if the data is not copyrighted orcopyright status is unknown). If there is an agreement with thecommunity, at 3249, a determination may be made whether there are anyrestrictions on the use of the data. If there are restrictions on theuse of the data, at 3251, applicable state laws may be reviewed.

At 3263, if there is not an agreement with the community (see 3247), adetermination may be made whether there is an online agreement (e.g.,for data originating from an Internet source). If there is an onlineagreement, at 3265, a determination may be made whether there are anyrestrictions on use. If there are no restrictions on use, adetermination may be made whether to contact the community, at 3277, toconfirm the ability to use that data. If there are restrictions on use,at 3267, a determination may be made as to whether the online agreementwas accepted. If it appears the online agreement was accepted, the flowmay return to 3251 to review state law applicable to the agreement. Ifthere is no evidence the online agreement was accepted, at 3269, adetermination may be made whether to contact the community at 3277. Ifthe online agreement was not accepted, or there is no evidence toindicate that it was accepted, then a determination may be made whetherto contact the community at 3277.

At 3253 (from 3251), a determination may be made whether therestrictions placed on the data are legal. If the restrictions arelegal, at 3255, the data may not be used. If the restrictions do notappear legal, at 3229, the relevant community may be contacted. If thecommunity is contacted, at 3227, negotiations may take place with thecommunity. At 3225, if the negotiations are successful, (e.g., thecommunity agrees to the usage of the data), the data may be used. At3233, if the negotiations are not successful, a determination may bemade whether to pursue legal action (e.g., against the community). If itis decided not to pursue legal action, at 3231, the data may not beused. At 3235, if legal action is pursued and is successful, the datamay be used 3237. If not successful, at 3231, the data may not be used.

At 3221, (from 3249) if there are no restrictions on use, applicablestate laws may be reviewed. At 3219, a determination may be made whetherthere are restrictions on use. At 3223, if there are no restrictions onuse, the data may be used. If there are some potential restrictions onuse at 3217 then a determination may be made whether or not the data isto be used based upon the potential restrictions on use, the data'svalue, its costs, any existing state attorney general opinions and caselaw opinions.

At 3207, (from 3211) a determination may be made whether the restrictionis legal. If the restriction is legal, at 3209, the data may not beused. At 3205, if the restriction does not look legal, a determinationmay be made whether to pursue legal action. At 3201, a determination maybe made whether the legal action was successful. If the legal action wasnot successful, at 3203, the data may not be used. If the legal actionwas successful, flow may return to 3247.

At 3277 (from 3263, 3265, or 3269), if there is not an online agreement,a determination may be made whether the community can be contacted. Ifcontacted and the negotiations are successful at 3279 then the data maybe used. If negotiations are not successful at 3279 then the state lawmay be reviewed at 3289. If the community is not contacted, at 3289,applicable state law may be reviewed. At 3295, a determination may bemade whether there are restrictions on use. If there are some potentialrestrictions on use at 3295 then, at 3298, a determination may be madewhether or not the data is to be used based upon the potentialrestrictions on use, the data's value, its costs, any existing stateattorney general opinions and case law opinions. If there are norestrictions, at 3296, the data may be used. At 3279, if the communitywas contacted, a determination may be made whether negotiation with thecommunity was successful. If negotiations with the community weresuccessful, at 3281, the data may be used. If the negotiations with thecommunity were not successful, then the state law may be reviewed at3289.

FIG. 33 illustrates a flowchart for data acquisition, according to anembodiment. In some embodiments, it should be noted that in variousembodiments of the methods described below, one or more of the elementsdescribed may be performed concurrently, in a different order thanshown, or may be omitted entirely. Other additional elements may also beperformed as desired. Parts or all of the process shown in the flowchartof FIG. 33 may be automated (e.g., performed by a computer system).

At 3301, (from 3241 of FIG. 32 c) if the digital parcel data is not inthe database 125, the relevant community may be contacted. At 3303, adetermination may be made whether the data is available from thecommunity. At 3305, if the data is not available from the community,relevant state laws may be reviewed. At 3307, a determination may bemade whether electronic format is required. If not, the process may endat 3317. If electronic format is required, at 3309, a determination maybe made whether to pursue legal action. If not, the process may end at3317. At 3311, a determination may be made whether the legal action hada favorable outcome. If there was not a favorable outcome, the processmay end at 3317. If there was a favorable outcome, at 3313, the systemmay wait for the data to become available, and, once available at 3313,the flow may return to 3319 to determine whether or not to purchase thedata.

At 3319 (from 3303), if the data is available, a determination may bemade whether to purchase the data based upon the costs, the restrictionson use, if any, and the terms of the agreement with the community, ifany. If the data is purchased, at 3323, the data may be used. At 3321,if the data is not purchased, relevant state laws may be reviewed toconsider the legality of the costs, restrictions on use, or terms of theagreement as required by the community. At 3325, a determination may bemade whether to contact the community based upon consideration of thecosts, restrictions on use, or terms of the agreement as required by thecommunity within the context of the state's laws. If not, the processmay end at 3327. If the community is contacted, at 3337, a determinationmay be made whether the negotiation with the community was successful.If the negotiation was not successful, at 3339, a determination may bemade whether to pursue legal action. If not, the process may end at3333. If legal action is pursued, at 3341, a determination may be madewhether the outcome was favorable. If the outcome was not favorable, theprocess may end at 3335. If the outcome was favorable, at 3343, the datamay be used.

At 3329 (from 3337) if the negotiation was successful, the data may bepurchased. At 3331, the data may then be used.

FIG. 34 illustrates the table structures for databaseprocessing/acquisition (e.g., for an Oracle™ database), according to anembodiment. In some embodiments, the parcel data may be corrected,modified, etc., for example, according to the scripts described above,during the data acquisition 3401 by the technician 3403 (e.g., using acomputer system). In some embodiments, ArcTools/ESRI 3405 may be usedduring a portion of the processing. After processing, the parcel datamay be put into an intermediate format (e.g., through a third partyprogram such as WinSCP (Windows secure copy) application). Theintermediate format may have fields as represented in shape-file format3413. Other formats are also contemplated. A mapping view program may beused to provide an interface between the intermediate shape-file 3413and a parcel_staging_table 3411. In some embodiments, the mapping viewprogram 3409 may have the form of a relational table. The mapping viewprogram 3409 may include links between fields in the shape-file 3413(e.g., field “RESOURCE_I”) and fields in the parcel_staging_table 3411(e.g., field “RESOURCE_INV_REL_ID”). In some embodiments, a link may benecessary because fields in the shape-file 3413 may be limited in size.Other reasons for using links are also contemplated. The mapping viewprogram 3409 may thus route attributes between the shape-file and theparcel_staging_table (e.g., to use in storing the parcel data in thecommon format database 125). In some embodiments, theparcel_staging_table 3411 may be used to create centroid staging data(e.g., create one or more centroids for the parcels in the shape-file3413) and/or populate additional data in the parcel_staging_table 3411(e g., the city, state, zip code, etc.).

In some embodiments, after the parcel data has been transferred to thedatabase, additional data may be supplied to the database by using aspatial query to a third party feature class (e.g., GUT Teleatlas™postal boundaries) for use by a USPS standardization engine. The USPSstandardization engine may find an address match for one or moreaddresses of the parcels in the shape file 3413/ parcel_staging_table3411. The additional data may be filled into the parcel_staging_table3411. In some embodiments, other mapping view programs 3417 may furthermap the parcel_staging_table 3411 to one or more tables (e.g.,county_table 3423, state_table 3429, and zip_code_table 3431). Othertables are also contemplated. In some embodiments, the county_table 3423may be used to verify the centroid address match. In some embodiments,the zip_code_table 3431 may be used to populate city, state, and/or zipcode in the parcel_staging_table 3411. Other tables may includecounty_aggr table 3427, parcel_load_param table 3433, parcel_table 3425,centroid_table 3435, and parcel_load_summary table 3437. In someembodiments, the parcel_load_summary_table 3437 may provide feedback onthe data loading process (e.g., as log file 701).

FIG. 35 illustrates a flowchart for database acquisition (e.g., for anOracle™ database), according to an embodiment. It should be noted thatin various embodiments of the methods described below, one or more ofthe elements described may be performed concurrently, in a differentorder than shown, or may be omitted entirely. Other additional elementsmay also be performed as desired. Parts or all of the process shown inthe flowchart of FIG. 35 may be automated (e.g., performed by a computersystem).

At 3501, parcel data may be acquired and processed (e.g., as seen inFIG. 6 a) for formatting, correction, etc. (see blocks 3401, 3403, and3405 in FIG. 34). In some embodiments, the result of the processing mayinclude a shape file 703. In some embodiments, the shape file 703 mayinclude a plurality of files (e.g., 5-6 files of various types with theparcel data in duplicate). Other file formats are also contemplated.

At 3503, the parcel data (e.g., in script file format) may be placedinto an intermediate format (e.g., by WinSCP) and/or an intermediatefile location. Other applications are also contemplated. In someembodiments, the shape file may be stored in an archive location and anintermediate file may hold the parcel data for further processing.

At 3505, the parcel data in the intermediate format/location may beprocessed by a script (e.g., a schedule script). The schedule script mayprocess the parcel data in the intermediate location and transform theparcel data (e.g., using an OraParcelLoader.sh tool (e.g., OGR2OGR))into a dataset that can be loaded into a database (e.g., an Oracle™database). Processing the parcel data may include filtering the data(e.g., by removing extraneous data not applicable to the database)and/or inserting the attribute data associated with the parcel data intoa parcel_staging_table 3411 for entry into a database (e.g., an Oracle™database).

At 3506, the geometries of the parcel data may be validated. A scriptmay examine the polygons defined by the parcel data to insure, forexample, the polygons are closed (i.e., complete). Other geometryvalidations are also contemplated. For example, extremely small parcels(e.g., less than 2 square inches of land) may be removed. Otherdimensions of parcels may also be removed.

At 3507, centroids (e.g., see centroid 403 in FIG. 4 a) may be created(i.e., calculated) for the parcel data. For example, a script(“Process_Parcel_Data.sql” in FIG. 34) may create centroids (e.g., whichmay be represented by latitude, longitude coordinates corresponding to aspatial centroid of the parcel) for one or more parcels in the parceldata and may load this centroid data into a structure (e.g.,centroid_staging_table 3419). The script may also clean the address dataassociated with the parcels (e.g., by removing extraneous characters,etc.), trim the address data (e.g., remove extra spaces), and/or find anassociated zip code, city, state, etc. for the address data. In someembodiments, a script (e.g., “Parcel_zip4sh”) may query a US PostalService (USPS) library to standardize (std) one or more addressesassociated with the parcels. For example, “street” in an address may beconverted to “St.” Other conventions are also contemplated.

At 3509, the centroids for the parcel data may be validated (e.g., witha spatial query). For example, the system or system user may determineif the calculated centroid (e.g., as represented by coordinates) iswithin a FIPS boundary corresponding to the FIPS code for thecorresponding parcel. In some embodiments, the FIPS boundary (which maybe represented by polygon coordinates) may be returned by querying adata set (e.g., from a third party dataset such as a county dataset fromGDT Teleatlas™ or other dataset source) using the corresponding FIPScode. In some embodiments, the corresponding FIPS code may be determinedfrom the attribute data for the parcel. If the centroid coordinates arespatially within the returned FIPS boundary corresponding to the FIPScode, the centroid may be determined to be valid. In some embodiments,the invalid centroids (e.g., which fall outside of their correspondingFIPS boundary) may be counted. In some embodiments, if the count exceedsa threshold (e.g., if >10 percent of the parcels (for the shape file)are not valid), then the parcel data may not be loaded to the databaseat 3517. Other thresholds are also contemplated. In some embodiments, anelectronic mail notification may be sent to a system user (e.g., atechnician). In some embodiments, if the count is less than a threshold,the loading process may continue.

At 3511, the parcel data may be compared to parcels in the database tobe replaced. In some embodiments, parcels may be replaced according toFIPS code (e.g., during an update, the parcels in the database with adesignated FIPS code may be replaced with the parcel data from a shapefile corresponding to the designated FIPS code). In some embodiments,the parcels to be removed/updated may be selected using a tabular queryon the database using the corresponding FIPS code (which may select theparcels in the database with that FIPS code.) Selecting may includehighlighting, flagging, etc. In some embodiments, the comparison mayinclude a footprint validation with a spatial query to compare thecalculated centroids (for the parcel data to be loaded) to thenon-selected parcels and parcels to be removed (i.e., selected parcels)in the database. In some embodiments, the footprint validation mayinclude two comparisons (other comparisons are also contemplated).According to a first comparison, if greater than a threshold (e.g., ifgreater than approximately 10 percent) of the calculated centroids arespatially found in existing parcels in the database that are notselected (i.e., parcels that would normally not be removed with thisupdate) then the load may be aborted. Other thresholds are alsocontemplated. In some embodiments, shape files and/or other file formatsfor the parcel data may correspond to one FIPS code. If greater than athreshold of parcels to be loaded are outside the FIPS code designatedfor their shape file, the load may be aborted.

In the second comparison, if greater than a threshold (e.g., if greaterthan approximately 10 percent) of the selected parcels are going to beremoved without a corresponding update/replacement parcel in the parceldata to be loaded, then the load may be aborted (other thresholds arealso contemplated). For example, if the shape file with the parcel datacovers a designated FIPS code that currently has 100 correspondingparcels in the database, and the shape file only has parcel data for 80parcels, 20 parcels in the database may be removed without replacementif the load is allowed to proceed. In some embodiments, the load maythus be aborted and a notification may be sent to a system user.

At 3513, the selected parcels may be removed. In some embodiments, theparcels (e.g., corresponding to a FIPS code) may be removed through atabular query. Other parcel selections are also contemplated (e.g., theparcels in a state may be selected and removed).

At 3515, if a parcel/centroid to be loaded has an associated addressthat is missing one or more elements (e.g., missing a city or zip code),then the missing elements may be populated via spatial query using theparcel centroid and a dataset (e.g., a third party postal boundary dataset from the US Postal Service (USPS)). In some embodiments, a look upon the dataset may be performed to determine an address corresponding toa boundary of the dataset that a corresponding centroid is spatially in,and the missing elements (e.g., city or zip code) corresponding to theboundary for that centroid may be returned and populated into a tablefor the corresponding parcel (e.g., placed in the parcel staging table3411 and/or other location). Other datasets are also contemplated.

At 3517, the parcel data and/or centroid data from the intermediateformat may be moved/committed into the database (e.g., an Oracle™database). In some embodiments, the parcel data may include thecoordinates of the parcel, the coordinates of the centroid, andattribute data (e.g., from parcel_staging_table 3411,centroid_staging_table 3419, county_table 3423, state_table 3429,zip_code_table 3431, county_aggr_table 3427, parcel_load_summary_table3433, parcel_table 3425, centroid_table 3435, parcel_load_summary_table3437, etc.) In some embodiments, the data may be loaded according to apredetermined footprint (e.g., of existing data) and/or moved into a newlocation of the database. Data to be loaded may be compared with dataalready in the database, and, if a correlation exists (e.g., if dataalready in the database has an address that matches the address ofparcel data to be loaded, and the data has not already been removed), afootprint may be developed to update the existing data withoutduplicating the data. In some embodiments, statistics regarding thecorrelation may be stored in the load summary table (e.g.,parcel_load_summary 3437). Sequence IDs may be developed for the data inthe database to assist in locating the data in the database for laterretrieval (e.g., sequence IDs may be assigned to parcel_staging_ID,parcel_load_summary_ID, centroid_staging_ID, etc. to be loaded). Otheraccess mechanisms are also contemplated.

At 3519, parcel addresses for parcel data in the database may bestandardized (e.g., using a standardization engine based on USPSdatasets). The parcel data in the database may be compared to USPSlookup tables/library (which may be provided by the USPS (e.g.,monthly)). Standardization may include finding a match for a parcel inthe USPS lookup tables/library using a spatial query (e.g., using theparcel or centroid coordinates). In some embodiments, if the data in theUSPS lookup tables/library is different than the data in the database,the database may be updated with the data from the USPS lookuptables/library. In some embodiments, the database may include theoriginal address for a parcel and a standardized (STD_) address for theparcel (e.g., in the parcel_table 3425). The standardized address mayinclude a standardized city, state, zip code, etc. from the USPS lookuptables/library. For example, “801 Main Street” may have a standardizedcounterpart of “801 Main St.”. Other standardizations are alsocontemplated. In some embodiments, if the standardized address in theUSPS lookup tables/library is different than the standardized address inthe database, the standardized address in the database may be replacedwith the new data from the USPS lookup tables/library. In someembodiments, if the data is different and/or removed, the data may beflagged for a technician to review. In some embodiments, the technicianmay be notified of the flagged data through an electronic mail (othernotifications are also contemplated). In some embodiments, thetechnician may make changes to the changed/removed data. In someembodiments, standardization may be done periodically (e.g., monthly).Other time periods are also contemplated.

At 3521, data tables in the database may be created and/or updated. Forexample, data tables for county information 3423, county aggregateinformation 3427, zip code information 3431, parcel load parameters3433, parcel data 3425, centroid data 3435, and parcel_load_summary 3437may be created and/or updated. The data may be updated if the parceldata to be loaded into the database will replace previous parcel dataalready in the database. Other data tables are also contemplated.

At 3523, a view script may link one or more tables and/or data in thedatabase for presentation and/or access by system users (e.g.,customers). For example, information from the parcel table 3425 andinformation from the centroid table 3435 may be linked such that asystem user viewing information on a parcel in the parcel table may alsoview associated information in the centroid table 3435. Other tables andlinks are also contemplated. In some embodiments, the data may bepresented through a web application 3437 (e.g., a web map services (WMS)or web feature service (WFS) application). Other web applications arealso contemplated. The web application 3437 may allow a customer toaccess parcel data through a data specific URL. For example, thecustomer may access the data to view through a graphical map view. Insome embodiments, the data may be extracted (e.g., by a GIS parceltechnician 3439). For example, the technician may extract dataassociated with a specific FIPS. In some embodiments, the technician3439 may also load data into the system for loading into the database.For example, the technician 3439 may receive data from a subset of acounty to merge with other data from the county for upload to thedatabase.

In some embodiments, parcel polygons for storage in the database mayrepresent administrative boundaries as defined by local authorities fora region. In some embodiments, polygons may fall in general categories,such as state or federal land, parks, right-of-way, or water bodies.These general category polygons may be included in the polygon boundarydata. In some embodiments, polygons may not include separate dataattributes in the data. For example, polygons may represent newconstruction without attribute assignments or may have attribute datathat is missing, incomplete, or unavailable. In some embodiments,polygons may share the same attribution. These polygons may have thesame attribute information as at least one other polygon and may bereferred to as multi-part polygons. In some embodiments, there may beoverlaps and other topological issues between polygons (Individualpolygon geometries may be validated, and spatial relationships betweenthe individual polygons may not be created).

In some embodiments, centroids may include a set of a coordinatescorresponding to the center of gravity of a polygon. Centroids may becalculated for polygons regardless of size or shape. For the calculatedcentroids that fall outside of the polygon that it represents, analternative placement inside the polygon may be used for the centroid.In some embodiments, centroids may be the result of filtering criteriathat can produce inaccurate results for location representation. Threecriteria that may indicate a need for locational problem correction foradditional centroid adjustment: (a) A lack of address data (e.g., theaddress data may be incomplete, missing, or unavailable for a polygon);(b) multi-part parcel status (attributes may not be unique and addressattributes may exist in more than one polygon); and (c) centroidsrepresenting parcels that have a large parcel area. In some embodiments,data may include polygon centroids that have unique address attributes.The centroids may represent any size or shape of polygon.

Embodiments of a subset or all (and portions or all) of the above may beimplemented by program instructions stored in a memory medium or carriermedium and executed by a processor. A memory medium may include any ofvarious types of memory devices or storage devices. The term “memorymedium” is intended to include an installation medium, e.g., a CD-ROM,floppy disks, or tape device; a computer system memory or random accessmemory such as DRAM, Double Data Rate Random Access Memory (DDR RAM),SRAM, EDO RAM, Rambus RAM, etc.; or a non-volatile memory such as amagnetic media, e.g., a hard drive, or optical storage. The memorymedium may comprise other types of memory as well, or combinationsthereof. In addition, the memory medium may be located in a firstcomputer in which the programs are executed, or may be located in asecond different computer that connects to the first computer over anetwork, such as the Internet. In the latter instance, the secondcomputer may provide program instructions to the first computer forexecution. The term “memory medium” may include two or more memorymediums that may reside in different locations, e.g., in differentcomputers that are connected over a network.

In some embodiments, a computer system at a respective participantlocation may include a memory medium(s) on which one or more computerprograms or software components according to one embodiment of thepresent invention may be stored. For example, the memory medium maystore one or more programs that are executable to perform the methodsdescribed herein. The memory medium may also store operating systemsoftware, as well as other software for operation of the computersystem.

In this patent, certain U.S. patents, U.S. patent applications, andother materials (e.g., articles) have been incorporated by reference.The text of such U.S. patents, U.S. patent applications, and othermaterials is, however, only incorporated by reference to the extent thatno conflict exists between such text and the other statements anddrawings set forth herein. In the event of such conflict, then any suchconflicting text in such incorporated by reference U.S. patents, U.S.patent applications, and other materials is specifically notincorporated by reference in this patent.

Further modifications and alternative embodiments of various aspects ofthe invention may be apparent to those skilled in the art in view ofthis description. Accordingly, this description is to be construed asillustrative only and is for the purpose of teaching those skilled inthe art the general manner of carrying out the invention. It is to beunderstood that the forms of the invention shown and described hereinare to be taken as embodiments. Elements and materials may besubstituted for those illustrated and described herein, parts andprocesses may be reversed, and certain features of the invention may beutilized independently, all as would be apparent to one skilled in theart after having the benefit of this description of the invention.Changes may be made in the elements described herein without departingfrom the spirit and scope of the invention as described in the followingclaims.

What is claimed is:
 1. A method of incorporating parcel data into adatabase, comprising: receiving parcel data from a first source, saidparcel data including boundary coordinates; converting the parcel datafrom the first source into a format for storage in a common formatdatabase; receiving parcel data from a second source; converting theparcel data from the second source into the format for storage in thecommon format database, including projecting the parcel data into acommon projection, checking spatial accuracy of the projected parceldata, integrating the projected parcel data with data to form,integrated parcel data, and repairing geometries of the integratedparcel data; storing the converted parcel data from the first source andthe integrated parcel data from the second source in the common formatdatabase; removing, by a processor, redundant parcel data between theconverted parcel data from the first source and integrated parcel datafrom the second source; and retrieving parcel data from the commonformat database in response to a user request, wherein storing theconverted parcel data from the first source and the integrated secondsource in the common format database includes receiving an indication toadd the converted parcel data from the first source and the integratedparcel data from the second source to the common format database, andloading the converted parcel data from the first source and theintegrated parcel data from the second source into the common formatdatabase using a spatial database interface.